From nobody Mon Dec 5 08:51:34 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 779BF129B9E for ; Mon, 5 Dec 2016 08:51:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.197 X-Spam-Level: X-Spam-Status: No, score=-7.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qHfyV6YykEIW for ; Mon, 5 Dec 2016 08:51:30 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B64B129BD8 for ; Mon, 5 Dec 2016 08:49:57 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 4BABDBE2C for ; Mon, 5 Dec 2016 16:49:55 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zlQaipj85sRK for ; Mon, 5 Dec 2016 16:49:51 +0000 (GMT) Received: from [10.87.48.75] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 4792DBE51 for ; Mon, 5 Dec 2016 16:49:51 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1480956591; bh=yd5TsVj/vHCWXAfok0vCR6Vp4ed84OUh2YEZKX7B+BY=; h=Subject:References:To:From:Date:In-Reply-To:From; b=GhXBcfE04+DXAauY7vADwz/NSt6BV2va+0kybZ7rDSSt2gANQzRz0PN5LGUgYH35/ n0tpk7bFu7fm3JDCgDdvnMmJnZtv9E7rr7+7fzECfEehktEzwjEhlOH6bm9kUdxBp+ 8TmZNu/xlV+KmPqGD0RPD28/GGBMLy7UDUCKUq1I= References: <148095648466.3337.34445310856110357.idtracker@ietfa.amsl.com> To: "saag@ietf.org" From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= X-Forwarded-Message-Id: <148095648466.3337.34445310856110357.idtracker@ietfa.amsl.com> Message-ID: <00f3e828-d50c-f3e7-2321-41429edcb620@cs.tcd.ie> Date: Mon, 5 Dec 2016 16:49:51 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <148095648466.3337.34445310856110357.idtracker@ietfa.amsl.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms030207000407040809070503" Archived-At: Subject: [saag] Fwd: Last Call: (Opportunistic Wireless Encryption) to Informational RFC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2016 16:51:33 -0000 This is a cryptographically signed message in MIME format. --------------ms030207000407040809070503 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable FYI, as previously discussed on this list, the authors figure this is now ready so I've started (an extended) IETF LC. Cheers, S. -------- Forwarded Message -------- Subject: Last Call: (Opportunistic Wireless Encryption) to Informational RFC Date: Mon, 05 Dec 2016 08:48:04 -0800 From: The IESG Reply-To: ietf@ietf.org To: IETF-Announce CC: draft-harkins-owe@ietf.org, stephen.farrell@cs.tcd.ie The IESG has received a request from an individual submitter to consider the following document: - 'Opportunistic Wireless Encryption' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2017-01-13. Exceptionally, comments may be= sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This memo specifies an extension to IEEE Std 802.11 to provide for opportunistic (unauthenticated) encryption to the wireless media. The file can be obtained via https://datatracker.ietf.org/doc/draft-harkins-owe/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-harkins-owe/ballot/ No IPR declarations have been submitted directly on this I-D. --------------ms030207000407040809070503 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjEyMDUx NjQ5NTFaMC8GCSqGSIb3DQEJBDEiBCDj8muzGuppH7WA6XxCSTFWKT5k01QcuNhOfM7mGaKL aDBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQAAmTT3E1aMyodOtuR5avwc0GsNQ+JxFhlWIKVrN0m5OS6aKWPVSRiK sjtgVN/2yKZXVLbBTPYpYnZFlovdnR019OA27FqDOze22sNsv7bc4upIpvngSfF3AHm2VGxV PUbEgZwIYuiW/Un4mT+8GsdPinrehbhnh2RmCWghQgZrW2FR6qz4ezVDFT1lS01fufPgmLnT ysDWXAJn2LECFltDy6hrTzueZnWg6Szn8fkm1zPsU/hFNDoso4OeIWZacDkPkSJi2PkY+jM2 RWL8z4t+hNpemkOqCcE7CcdMCC1UcXjr9Z0JZPDqnkczJC+lRWHAwrEL5KLUl8aX1j01cZRd AAAAAAAA --------------ms030207000407040809070503-- From nobody Sun Dec 18 04:23:20 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86030129534 for ; Sun, 18 Dec 2016 04:23:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.999 X-Spam-Level: X-Spam-Status: No, score=-4.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-3.1] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zzbiqoB9uYz6 for ; Sun, 18 Dec 2016 04:23:14 -0800 (PST) Received: from mail.rozanak.com (mail.rozanak.com [IPv6:2a01:238:42ad:1500:aa19:4238:e48f:61cf]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48C17129521 for ; Sun, 18 Dec 2016 04:23:14 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by mail.rozanak.com (Postfix) with ESMTP id 5FCED25CA2DB for ; Sun, 18 Dec 2016 12:23:12 +0000 (UTC) X-Virus-Scanned: amavisd-new at rozanak.com Received: from mail.rozanak.com ([127.0.0.1]) by localhost (mail.rozanak.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uROgfI_7wVl6 for ; Sun, 18 Dec 2016 13:23:11 +0100 (CET) Received: from localhost.localdomain (p200300864F7BDE19F2DEF1FFFE58C5D4.dip0.t-ipconnect.de [IPv6:2003:86:4f7b:de19:f2de:f1ff:fe58:c5d4]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.rozanak.com (Postfix) with ESMTPSA id 66DA525CA08F for ; Sun, 18 Dec 2016 13:23:11 +0100 (CET) To: saag@ietf.org From: Hosnieh Rafiee Message-ID: <39ed344a-2f66-5898-6c99-368779c8bb73@rozanak.com> Date: Sun, 18 Dec 2016 13:23:03 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="2VAwCAEPDif1mu2t7NrRuapN1NNV2fIGc" Archived-At: Subject: [saag] Question about PKI - certificate serial number X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Dec 2016 12:23:19 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --2VAwCAEPDif1mu2t7NrRuapN1NNV2fIGc Content-Type: multipart/mixed; boundary="5WdXkQmBd3CePmHvw4fv3vQCnvsW4dJT3"; protected-headers="v1" From: Hosnieh Rafiee To: saag@ietf.org Message-ID: <39ed344a-2f66-5898-6c99-368779c8bb73@rozanak.com> Subject: Question about PKI - certificate serial number --5WdXkQmBd3CePmHvw4fv3vQCnvsW4dJT3 Content-Type: multipart/alternative; boundary="------------988B79993DBBA5F3B8F685F9" This is a multi-part message in MIME format. --------------988B79993DBBA5F3B8F685F9 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello, In RFC 5280, I read that the issuer of the certificate, assigned a unique number to each certificate and call it a serial number. I assume that this serial number is sent by the CA to client whenever the client asks for the certificate of this intermediate CA. That means the attacker might be able to eavesdrop this serial number. is this assumption true? that means the attacker might be able also to spoof and use the same serial number for its fake Certificate. I guess I am confused in some part of processes .... what if the client only have the list of trusted anchors received from root or issuer CA that includes certificate serial number, issuer and some other information as mentioned in the above RFC, how would be the serial numbers protected against spoofing attack? specially if the client verification method is only based on trusting this list and not go through asking the issuer to download the intermediate CA certificate from the repository? The second question is that, when root CA is not always online, that means the CRL list is valid for a certain period of time. if during this time a certificate is compromised, the root needs to send a new CRL to clients. In this case, if the attacker perform replay attack with the old list, is there any in use method to avoid such attack? I would appreciate if someone can clarify these cases or point me to the right RFC. Thanks, Best, Hosnieh --------------988B79993DBBA5F3B8F685F9 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Hel= lo,

In RFC 5280, I read that the issuer of the certificate, assigned a unique number to each certificate and call it a serial number. I assume that this serial number is sent by the CA to client whenever the client asks for the certificate of this intermediate CA. That means the attacker might be able to eavesdrop this serial number.=C2=A0 is this assumption true? th= at means the attacker might be able also to spoof and use the same serial number for its fake Certificate.

I guess I am confused in some part of processes .... what if=C2=A0= the client only have the list of trusted anchors received from root or issuer CA that includes certificate serial number, issuer and some other information as mentioned in the above RFC, how would be the serial numbers protected against spoofing attack? specially if the client verification method is only based on trusting this list and not go through asking the issuer to download the intermediate CA certificate from the repository?

The= second question is that, when root CA is not always online, that means the CRL list is valid for a certain period of time. if during this time a certificate is compromised, the root needs to send a new CRL to clients. In this case, if the attacker perform=C2=A0 replay attack with the old list, is ther= e any in use method to avoid such attack?

I would appreciate if someone can clarify these cases or point me to the right RFC.

Tha= nks,

Bes= t,

Hos= nieh


--------------988B79993DBBA5F3B8F685F9-- --5WdXkQmBd3CePmHvw4fv3vQCnvsW4dJT3-- --2VAwCAEPDif1mu2t7NrRuapN1NNV2fIGc Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJYVn+uAAoJEOyUqFLKlLcnCJ4QAMmutvnd07WR3xG0i+mL0nE5 Ko6MHLHCGPBJBy3U3xl6RXra8SFZjvMp5nGrbLUjf3hhjc/zT76rHWXJEgsccMBV NIb15KFWb1JYeR9gd//FB7+3JHVq5P+1d4emtsI0Dy66ZrZJbSSmFBy8iN13mqsI iy0LffqI311b04/S0YVoSx9W+AMpXk6379vRiFZtZqYtXw9oDoiq5YWMarLPSWd6 3YK3huZ4ZqBl256mp7X/4qIA0tOxm8OK4Co1AKf/hJQPtJrFWNyyKfSFmqd3JJ5p lfODiaLqAeh0I8NPHkBdL7U1ViyBYhC74od8YD/v9AqRIDRHawAHmZNrHxzOvqPk Ztv1d1qSU9AdT1H8rBvTYqqLL0f+F6Kg3Gu0TooOqajh4IuNGF/X49mOJ+8EDDrz 0G4jQdBoYvIjarddL8A57IQnXqfJKNhIzqbLpdheULi3OyGQTXd53nbZYwsqwqJh NWkNOJ3N6rqcKhXtqeTCcs51UxQzp/CAizxRpPrXRG8sgXFree8cZVL8WWXzusNT Ne+GAFYlbQQwA+VwxIighgg2OSLfd34S66jrYJH/h9IdYyvIDBQ8vc3dV6W1Ecnr kyWQkros08WCuWrPizPKxaqWn7fgCzEe/53/ZXLYu9uORz6S4XujuZiwJWjbs6QM c3QHRFxTqSUhBqKqR96p =TE/i -----END PGP SIGNATURE----- --2VAwCAEPDif1mu2t7NrRuapN1NNV2fIGc-- From nobody Sun Dec 18 05:09:00 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BB7412941D for ; Sun, 18 Dec 2016 05:08:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IMB5lrPxmGWV for ; Sun, 18 Dec 2016 05:08:56 -0800 (PST) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DC75129418 for ; Sun, 18 Dec 2016 05:08:56 -0800 (PST) Received: by mail-wm0-x233.google.com with SMTP id g23so72782686wme.1 for ; Sun, 18 Dec 2016 05:08:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=6BfqDa53QlHLh7NGEyMd1k1066tJy46QzmkbjrQkH+o=; b=YUCKGvvLzzYWVh9/p0gex/dCreEREeFkUGdgYA1QGnlKrtzN77UMa8h6jzb81LsjWu RmQJzi9iRknUDkodlxALpNyxkmkiA3DdjdT4/dSkSyFDytU03Bj9JqRzZ90KcqH3A1AV tiJi+RX1FauaoqDFWJjkKNZ7LCU9+qJStUNRqj9tctc4RVk8PM46LN6M0u2kkJyPxggM GGG7V8EB2+jG1/Xh7Pm+7RuAjnAI3rcOJDsicUYrjMfh4Fjx4EkXBo4UFXNjs2SI6n9Y fjp4bH9wFusHG8QJXzqz4HDxq+1JyIjJGo/w9NdkJ2VRczgdPEm0ZF2u1Rj05nYsYrFC qIJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=6BfqDa53QlHLh7NGEyMd1k1066tJy46QzmkbjrQkH+o=; b=LD28IBkPk5ExNkRLP783RAF6HP5bFrT6HmXwqcCyuUDl2EMXyL34xwn/w8GAy5kwDu ViQiifwkvQJHYk3AwoCxfNQKrG/P7iERC9KrMcETScoUvzxKKjKp2Xh+yITGk6kHIq/j ysYUsth8Kpga0bjH2XucwyNh42+Q4BWXO7ksm8lRn9DI+gdH7Lzg5a65nlm1QKxxsYA1 YkmIUjWfrhEeAyPcoqMi489IpnKFNLqEwbZqbmYkUHchTY/BcM9WLuHSJHM7BwU20fqv 6r33Zx2uzo93aEnP8oRXi9WpOlt8Pp2Qv/Gu83sYzYpaG2nIZuwW4//eu8I3vOFUYLuk JE5A== X-Gm-Message-State: AIkVDXJ/rkHds7y3frUVJhQtNDwtQOYRXgLiRYq02CcFBrXcDiYQ8ijX/CkYihLdXEizbQ== X-Received: by 10.28.141.18 with SMTP id p18mr9532938wmd.31.1482066534823; Sun, 18 Dec 2016 05:08:54 -0800 (PST) Received: from [192.168.137.206] ([176.13.2.76]) by smtp.gmail.com with ESMTPSA id b3sm15927055wjy.40.2016.12.18.05.08.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 18 Dec 2016 05:08:54 -0800 (PST) From: Yoav Nir Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_827D011A-25BC-4484-84EB-CF68A801BA5B" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Sun, 18 Dec 2016 15:08:51 +0200 In-Reply-To: <39ed344a-2f66-5898-6c99-368779c8bb73@rozanak.com> To: Hosnieh Rafiee References: <39ed344a-2f66-5898-6c99-368779c8bb73@rozanak.com> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: Security Area Advisory Group Subject: Re: [saag] Question about PKI - certificate serial number X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Dec 2016 13:08:58 -0000 --Apple-Mail=_827D011A-25BC-4484-84EB-CF68A801BA5B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, Hosnieh On 18 Dec 2016, at 14:23, Hosnieh Rafiee wrote: > Hello, >=20 >=20 > In RFC 5280, I read that the issuer of the certificate, assigned a = unique number to each certificate and call it a serial number. I assume = that this serial number is sent by the CA to client whenever the client = asks for the certificate of this intermediate CA. >=20 The issuer of the certificate (=3D the Certificate Authority) assigns = the serial number when issuing the certificate, whether this certificate = is for an End Entity or an Intermediate CA. > That means the attacker might be able to eavesdrop this serial number. = is this assumption true? that means the attacker might be able also to = spoof and use the same serial number for its fake Certificate. >=20 The serial number, and indeed the entire certificate is not secret = information. It is sent in the clear. There may be privacy concerns = about the content of some fields, but this is a case where privacy is = not security. The attacker is welcome to use the same serial number on a fake = certificate. It should not be able to generate a valid signature on that = fake certificate. > I guess I am confused in some part of processes .... what if the = client only have the list of trusted anchors received from root or = issuer CA that includes certificate serial number, issuer and some other = information as mentioned in the above RFC, how would be the serial = numbers protected against spoofing attack? specially if the client = verification method is only based on trusting this list and not go = through asking the issuer to download the intermediate CA certificate = from the repository? >=20 For the root CAs there is not protection. The certificates of the root = CAs serve only as vessels for the public key within them. The list of = trusted CA is part of the configuration of a Relying Party. The serial = numbers in other certificate are part of the tbsCertificate structure = (section 4.1.1.1) and are thus protected by the signature.=20 > The second question is that, when root CA is not always online, that = means the CRL list is valid for a certain period of time. if during this = time a certificate is compromised, the root needs to send a new CRL to = clients. In this case, if the attacker perform replay attack with the = old list, is there any in use method to avoid such attack? >=20 Not with CRLs. And you don=E2=80=99t need an attack either. If I have = just fetched a CRL for which the nextUpdate field is January 1st 2017, I = am allowed to cache it until then. Any compromise that happens in that = time =E2=80=94 I won=E2=80=99t know about it until January 1st. And this = is true even with no CA downtime. Add CA downtime, and I might use the = cached CRL longer. The CA does not actively send fresh CRLs to relying = parties. It waits for them. OCSP usually has shorter validity periods, but the mechanism is the = same. The relying party is allowed to cache the responses until the = nextUpdate time. > I would appreciate if someone can clarify these cases or point me to = the right RFC. >=20 I don=E2=80=99t know that there=E2=80=99s anything that explains this = beyond 5280. Yoav --Apple-Mail=_827D011A-25BC-4484-84EB-CF68A801BA5B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi, Hosnieh

On 18 Dec 2016, at 14:23, Hosnieh Rafiee <ietf@rozanak.com> = wrote:
=20 =20

Hello,


In RFC 5280, I read that the issuer of the certificate, assigned a unique number to each certificate and call it a serial number. I assume that this serial number is sent by the CA to client whenever the client asks for the certificate of this intermediate CA. =

The issuer of the = certificate (=3D the Certificate Authority) assigns the serial number = when issuing the certificate, whether this certificate is for an End = Entity or an Intermediate CA.

That means the attacker might be = able to eavesdrop this serial number.  is this assumption true? = that means the attacker might be able also to spoof and use the same serial number for its fake Certificate.

The serial number, = and indeed the entire certificate is not secret information. It is sent = in the clear. There may be privacy concerns about the content of some = fields, but this is a case where privacy is not security.

The attacker is welcome to use the same serial = number on a fake certificate. It should not be able to generate a valid = signature on that fake certificate.

I guess I am confused in some part of processes .... what = if  the client only have the list of trusted anchors received from root or issuer CA that includes certificate serial number, issuer and some other information as mentioned in the above RFC, how would be the serial numbers protected against spoofing attack? specially if the client verification method is only based on trusting this list and not go through asking the issuer to download the intermediate CA certificate from the repository?

For = the root CAs there is not protection. The certificates of the root CAs = serve only as vessels for the public key within them. The list of = trusted CA is part of the configuration of a Relying Party.  The = serial numbers in other certificate are part of the tbsCertificate = structure (section 4.1.1.1) and are thus protected by the = signature. 

The second question is that, when root CA is not always online, that means the CRL list is valid for a certain period of time. if during this time a certificate is compromised, the root needs to send a new CRL to clients. In this case, if the attacker perform  replay attack with the old list, is = there any in use method to avoid such attack?

Not with CRLs. And = you don=E2=80=99t need an attack either. If I have just fetched a CRL = for which the nextUpdate field is January 1st 2017, I am allowed to = cache it until then. Any compromise that happens in that time =E2=80=94 = I won=E2=80=99t know about it until January 1st. And this is true even = with no CA downtime. Add CA downtime, and I might use the cached CRL = longer. The CA does not actively send fresh CRLs to relying parties. It = waits for them.

OCSP usually has = shorter validity periods, but the mechanism is the same. The relying = party is allowed to cache the responses until the nextUpdate time.

I would appreciate if someone can clarify these cases or point me to the right RFC.

I don=E2=80=99t know = that there=E2=80=99s anything that explains this beyond = 5280.

Yoav


= --Apple-Mail=_827D011A-25BC-4484-84EB-CF68A801BA5B-- From nobody Mon Dec 19 07:36:40 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67362129B99 for ; Mon, 19 Dec 2016 07:36:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=fail (1024-bit key) reason="fail (message has been altered)" header.from=David.Black@dell.com header.d=dell.com; dkim=pass (1024-bit key) header.d=dell.com header.b=lFNrmuLV; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=g981ANqi Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YAlRTeLqXFPp for ; Mon, 19 Dec 2016 07:36:28 -0800 (PST) Received: from esa7.dell-outbound.iphmx.com (esa7.dell-outbound.iphmx.com [68.232.153.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D930129B97 for ; Mon, 19 Dec 2016 07:36:24 -0800 (PST) DomainKey-Signature: s=smtpout; d=dell.com; c=simple; q=dns; h=Received:From:Received:Received:X-DKIM:DKIM-Signature: X-DKIM:Received:Received:Received:To:Subject:Thread-Topic: Thread-Index:Date:Message-ID:References:In-Reply-To: Accept-Language:Content-Language:X-MS-Has-Attach: X-MS-TNEF-Correlator:x-originating-ip:Content-Type: MIME-Version:X-Sentrion-Hostname:X-RSA-Classifications; b=m6KtKHp8Mylj3rtP4uzMN9Q0xOVxu5i8d8JJMncnr8XvdQPhyQGCWa/N dFnfjyG8nAKRe9C1kga07CNnIL47E+yfwRStB9S5l+kjX2I7RNV6KhjVh UljoHPT/3YiAXcpfxP88cXvwXRHks50m7XR92CnaHns2bAf3xK8svPoua w=; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1482161784; x=1513697784; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=iHiDhkpOYYwPD7NaOLNDbIHF6y7hMmn2II1B5qbUHWc=; b=lFNrmuLVoUMvXT6CIg7w6ywGU0pBDIp0Lb3PNc193RtPCy5Zot6kUyci ZF68aGQoyONoGb7iZ18gIpIwMj1wKSYH3KsTLrsT5mgbALqXcPvMi+qpZ V7BskQiHbT1DIMlbPuUmlsAlFBaXLmlyxdbp4LFJgIclchGs+IUEEoxQl A=; Received: from esa2.dell-outbound2.iphmx.com ([68.232.153.202]) by esa7.dell-outbound.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Dec 2016 09:36:23 -0600 From: "Black, David" Received: from mailuogwdur.emc.com ([128.221.224.79]) by esa2.dell-outbound2.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Dec 2016 21:36:23 +0600 Received: from maildlpprd55.lss.emc.com (maildlpprd55.lss.emc.com [10.106.48.159]) by mailuogwprd51.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id uBJFaLR8029313 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 19 Dec 2016 10:36:22 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd51.lss.emc.com uBJFaLR8029313 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1482161782; bh=nEZsckwVP2cT57kbua6gGtienh0=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=g981ANqiwHhUzI5JeSEI61wHWY7SN0s5Cgwm2fdqN7Rmks4+GVHpy/pUqS/tAXjdF uRmngidG+kG8g2wb/yjHzul+og7/LSCF4iuhwm4AMociivsObTPsHJ9+1wi7+NLnxc 0cMCF2PFFoHR8Nj0SSzkBnHraeU6qMcpZjC6WfIE= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd51.lss.emc.com uBJFaLR8029313 Received: from mailusrhubprd52.lss.emc.com (mailusrhubprd52.lss.emc.com [10.106.48.25]) by maildlpprd55.lss.emc.com (RSA Interceptor) for ; Mon, 19 Dec 2016 10:36:05 -0500 Received: from MXHUB317.corp.emc.com (MXHUB317.corp.emc.com [10.146.3.95]) by mailusrhubprd52.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id uBJFaCSa004360 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL) for ; Mon, 19 Dec 2016 10:36:13 -0500 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB317.corp.emc.com ([10.146.3.95]) with mapi id 14.03.0266.001; Mon, 19 Dec 2016 10:36:12 -0500 To: Security Area Advisory Group Thread-Topic: [saag] Question about PKI - certificate serial number Thread-Index: AQHSWSmJ0P8bTEE/F0CTLJoqD0TkuaEOAT+AgAFlVmA= Date: Mon, 19 Dec 2016 15:36:11 +0000 Message-ID: References: <39ed344a-2f66-5898-6c99-368779c8bb73@rozanak.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.252.77.69] Content-Type: multipart/alternative; boundary="_000_CE03DB3D7B45C245BCA0D243277949362F797437MX307CL04corpem_" MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd52.lss.emc.com X-RSA-Classifications: public Archived-At: Subject: Re: [saag] Question about PKI - certificate serial number X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2016 15:36:30 -0000 --_000_CE03DB3D7B45C245BCA0D243277949362F797437MX307CL04corpem_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGF2aWQ+IFNtYWxsIGNsYXJpZmljYXRpb24gaW5saW5lIC4uLi4NCg0KVGhhbmtzLCAtLURhdmlk DQoNCkZyb206IHNhYWcgW21haWx0bzpzYWFnLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBP ZiBZb2F2IE5pcg0KU2VudDogU3VuZGF5LCBEZWNlbWJlciAxOCwgMjAxNiA4OjA5IEFNDQpUbzog SG9zbmllaCBSYWZpZWUNCkNjOiBTZWN1cml0eSBBcmVhIEFkdmlzb3J5IEdyb3VwDQpTdWJqZWN0 OiBSZTogW3NhYWddIFF1ZXN0aW9uIGFib3V0IFBLSSAtIGNlcnRpZmljYXRlIHNlcmlhbCBudW1i ZXINCg0KSGksIEhvc25pZWgNCg0KT24gMTggRGVjIDIwMTYsIGF0IDE0OjIzLCBIb3NuaWVoIFJh ZmllZSA8aWV0ZkByb3phbmFrLmNvbTxtYWlsdG86aWV0ZkByb3phbmFrLmNvbT4+IHdyb3RlOg0K SGVsbG8sDQoNCkluIFJGQyA1MjgwLCBJIHJlYWQgdGhhdCB0aGUgaXNzdWVyIG9mIHRoZSBjZXJ0 aWZpY2F0ZSwgYXNzaWduZWQgYSB1bmlxdWUgbnVtYmVyIHRvIGVhY2ggY2VydGlmaWNhdGUgYW5k IGNhbGwgaXQgYSBzZXJpYWwgbnVtYmVyLiBJIGFzc3VtZSB0aGF0IHRoaXMgc2VyaWFsIG51bWJl ciBpcyBzZW50IGJ5IHRoZSBDQSB0byBjbGllbnQgd2hlbmV2ZXIgdGhlIGNsaWVudCBhc2tzIGZv ciB0aGUgY2VydGlmaWNhdGUgb2YgdGhpcyBpbnRlcm1lZGlhdGUgQ0EuDQpUaGUgaXNzdWVyIG9m IHRoZSBjZXJ0aWZpY2F0ZSAoPSB0aGUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5KSBhc3NpZ25zIHRo ZSBzZXJpYWwgbnVtYmVyIHdoZW4gaXNzdWluZyB0aGUgY2VydGlmaWNhdGUsIHdoZXRoZXIgdGhp cyBjZXJ0aWZpY2F0ZSBpcyBmb3IgYW4gRW5kIEVudGl0eSBvciBhbiBJbnRlcm1lZGlhdGUgQ0Eu DQpUaGF0IG1lYW5zIHRoZSBhdHRhY2tlciBtaWdodCBiZSBhYmxlIHRvIGVhdmVzZHJvcCB0aGlz IHNlcmlhbCBudW1iZXIuICBpcyB0aGlzIGFzc3VtcHRpb24gdHJ1ZT8gdGhhdCBtZWFucyB0aGUg YXR0YWNrZXIgbWlnaHQgYmUgYWJsZSBhbHNvIHRvIHNwb29mIGFuZCB1c2UgdGhlIHNhbWUgc2Vy aWFsIG51bWJlciBmb3IgaXRzIGZha2UgQ2VydGlmaWNhdGUuDQpUaGUgc2VyaWFsIG51bWJlciwg YW5kIGluZGVlZCB0aGUgZW50aXJlIGNlcnRpZmljYXRlIGlzIG5vdCBzZWNyZXQgaW5mb3JtYXRp b24uIEl0IGlzIHNlbnQgaW4gdGhlIGNsZWFyLiBUaGVyZSBtYXkgYmUgcHJpdmFjeSBjb25jZXJu cyBhYm91dCB0aGUgY29udGVudCBvZiBzb21lIGZpZWxkcywgYnV0IHRoaXMgaXMgYSBjYXNlIHdo ZXJlIHByaXZhY3kgaXMgbm90IHNlY3VyaXR5Lg0KDQpUaGUgYXR0YWNrZXIgaXMgd2VsY29tZSB0 byB1c2UgdGhlIHNhbWUgc2VyaWFsIG51bWJlciBvbiBhIGZha2UgY2VydGlmaWNhdGUuIEl0IHNo b3VsZCBub3QgYmUgYWJsZSB0byBnZW5lcmF0ZSBhIHZhbGlkIHNpZ25hdHVyZSBvbiB0aGF0IGZh a2UgY2VydGlmaWNhdGUuDQoNCkkgZ3Vlc3MgSSBhbSBjb25mdXNlZCBpbiBzb21lIHBhcnQgb2Yg cHJvY2Vzc2VzIC4uLi4gd2hhdCBpZiAgdGhlIGNsaWVudCBvbmx5IGhhdmUgdGhlIGxpc3Qgb2Yg dHJ1c3RlZCBhbmNob3JzIHJlY2VpdmVkIGZyb20gcm9vdCBvciBpc3N1ZXIgQ0EgdGhhdCBpbmNs dWRlcyBjZXJ0aWZpY2F0ZSBzZXJpYWwgbnVtYmVyLCBpc3N1ZXIgYW5kIHNvbWUgb3RoZXIgaW5m b3JtYXRpb24gYXMgbWVudGlvbmVkIGluIHRoZSBhYm92ZSBSRkMsIGhvdyB3b3VsZCBiZSB0aGUg c2VyaWFsIG51bWJlcnMgcHJvdGVjdGVkIGFnYWluc3Qgc3Bvb2ZpbmcgYXR0YWNrPyBzcGVjaWFs bHkgaWYgdGhlIGNsaWVudCB2ZXJpZmljYXRpb24gbWV0aG9kIGlzIG9ubHkgYmFzZWQgb24gdHJ1 c3RpbmcgdGhpcyBsaXN0IGFuZCBub3QgZ28gdGhyb3VnaCBhc2tpbmcgdGhlIGlzc3VlciB0byBk b3dubG9hZCB0aGUgaW50ZXJtZWRpYXRlIENBIGNlcnRpZmljYXRlIGZyb20gdGhlIHJlcG9zaXRv cnk/DQpGb3IgdGhlIHJvb3QgQ0FzIHRoZXJlIGlzIG5vdCBwcm90ZWN0aW9uLiBUaGUgY2VydGlm aWNhdGVzIG9mIHRoZSByb290IENBcyBzZXJ2ZSBvbmx5IGFzIHZlc3NlbHMgZm9yIHRoZSBwdWJs aWMga2V5IHdpdGhpbiB0aGVtLiBUaGUgbGlzdCBvZiB0cnVzdGVkIENBIGlzIHBhcnQgb2YgdGhl IGNvbmZpZ3VyYXRpb24gb2YgYSBSZWx5aW5nIFBhcnR5LiAgVGhlIHNlcmlhbCBudW1iZXJzIGlu IG90aGVyIGNlcnRpZmljYXRlIGFyZSBwYXJ0IG9mIHRoZSB0YnNDZXJ0aWZpY2F0ZSBzdHJ1Y3R1 cmUgKHNlY3Rpb24gNC4xLjEuMSkgYW5kIGFyZSB0aHVzIHByb3RlY3RlZCBieSB0aGUgc2lnbmF0 dXJlLg0KDQpEYXZpZD4gU3BlY2lmaWNhbGx5LCB0aGUgdHJ1c3QgYW5jaG9yIGluY2x1ZGVzIHRo ZSBpc3N1ZXLigJlzIHB1YmxpYyBrZXksIHdoaWNoIGlzIHdoeSB0aGUgYXR0YWNrZXIgY2Fu4oCZ dCBnZW5lcmF0ZSBhIHZhbGlkIHNpZ25hdHVyZSBldmVuIGlmIHNoZSB1c2VzIHRoZSBzYW1lIHNl cmlhbCBudW1iZXIgaW4gaGVyIGZha2UgY2VydGlmaWNhdGUgLSBzaGUgZG9lc27igJl0IGhhdmUg dGhlIGlzc3VlcuKAmXMgcHJpdmF0ZSBrZXkuICBBbHNvLCBjbGllbnQgdmVyaWZpY2F0aW9uIGlu dm9sdmVzIGEgbG90IG1vcmUgdGhhbiBqdXN0IGNoZWNraW5nIHRoZSBzZXJpYWwgbnVtYmVyIC0g c2VlIHRoZSBDZXJ0aWZpY2F0ZSBQYXRoIFZhbGlkYXRpb24gYWxnb3JpdGhtIGluIFNlY3Rpb24g NiBvZiBSRkMgNTI4MCAtIGV2ZXJ5dGhpbmcgdGhlcmUgbmVlZHMgdG8gYmUgZG9uZSwgYXMgc2tp cHBpbmcgc3RlcHMgdGhhdCBhcHBlYXIgdG8gYmUgaXJyZWxldmFudCByaXNrcyBpbnRyb2R1Y2lu ZyBzdWJ0bGUgc2VjdXJpdHkgZmxhd3MuDQpUaGUgc2Vjb25kIHF1ZXN0aW9uIGlzIHRoYXQsIHdo ZW4gcm9vdCBDQSBpcyBub3QgYWx3YXlzIG9ubGluZSwgdGhhdCBtZWFucyB0aGUgQ1JMIGxpc3Qg aXMgdmFsaWQgZm9yIGEgY2VydGFpbiBwZXJpb2Qgb2YgdGltZS4gaWYgZHVyaW5nIHRoaXMgdGlt ZSBhIGNlcnRpZmljYXRlIGlzIGNvbXByb21pc2VkLCB0aGUgcm9vdCBuZWVkcyB0byBzZW5kIGEg bmV3IENSTCB0byBjbGllbnRzLiBJbiB0aGlzIGNhc2UsIGlmIHRoZSBhdHRhY2tlciBwZXJmb3Jt ICByZXBsYXkgYXR0YWNrIHdpdGggdGhlIG9sZCBsaXN0LCBpcyB0aGVyZSBhbnkgaW4gdXNlIG1l dGhvZCB0byBhdm9pZCBzdWNoIGF0dGFjaz8NCk5vdCB3aXRoIENSTHMuIEFuZCB5b3UgZG9u4oCZ dCBuZWVkIGFuIGF0dGFjayBlaXRoZXIuIElmIEkgaGF2ZSBqdXN0IGZldGNoZWQgYSBDUkwgZm9y IHdoaWNoIHRoZSBuZXh0VXBkYXRlIGZpZWxkIGlzIEphbnVhcnkgMXN0IDIwMTcsIEkgYW0gYWxs b3dlZCB0byBjYWNoZSBpdCB1bnRpbCB0aGVuLiBBbnkgY29tcHJvbWlzZSB0aGF0IGhhcHBlbnMg aW4gdGhhdCB0aW1lIOKAlCBJIHdvbuKAmXQga25vdyBhYm91dCBpdCB1bnRpbCBKYW51YXJ5IDFz dC4gQW5kIHRoaXMgaXMgdHJ1ZSBldmVuIHdpdGggbm8gQ0EgZG93bnRpbWUuIEFkZCBDQSBkb3du dGltZSwgYW5kIEkgbWlnaHQgdXNlIHRoZSBjYWNoZWQgQ1JMIGxvbmdlci4gVGhlIENBIGRvZXMg bm90IGFjdGl2ZWx5IHNlbmQgZnJlc2ggQ1JMcyB0byByZWx5aW5nIHBhcnRpZXMuIEl0IHdhaXRz IGZvciB0aGVtLg0KDQpPQ1NQIHVzdWFsbHkgaGFzIHNob3J0ZXIgdmFsaWRpdHkgcGVyaW9kcywg YnV0IHRoZSBtZWNoYW5pc20gaXMgdGhlIHNhbWUuIFRoZSByZWx5aW5nIHBhcnR5IGlzIGFsbG93 ZWQgdG8gY2FjaGUgdGhlIHJlc3BvbnNlcyB1bnRpbCB0aGUgbmV4dFVwZGF0ZSB0aW1lLg0KDQpJ IHdvdWxkIGFwcHJlY2lhdGUgaWYgc29tZW9uZSBjYW4gY2xhcmlmeSB0aGVzZSBjYXNlcyBvciBw b2ludCBtZSB0byB0aGUgcmlnaHQgUkZDLg0KSSBkb27igJl0IGtub3cgdGhhdCB0aGVyZeKAmXMg YW55dGhpbmcgdGhhdCBleHBsYWlucyB0aGlzIGJleW9uZCA1MjgwLg0KDQpZb2F2DQoNCg0K --_000_CE03DB3D7B45C245BCA0D243277949362F797437MX307CL04corpem_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEOw0KCWZvbnQtd2VpZ2h0Om5vcm1hbDsNCglmb250LXN0 eWxlOm5vcm1hbDsNCgl0ZXh0LWRlY29yYXRpb246bm9uZSBub25lO30NCi5Nc29DaHBEZWZhdWx0 DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBh Z2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBp biAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30N Ci0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6 ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2 OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0t LT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxl Ij4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+RGF2aWQmZ3Q7IFNtYWxsIGNs YXJpZmljYXRpb24gaW5saW5lIC4uLi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGFua3MsIC0tRGF2aWQ8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVl IDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBp biAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBzYWFn IFttYWlsdG86c2FhZy1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5Zb2F2 IE5pcjxicj4NCjxiPlNlbnQ6PC9iPiBTdW5kYXksIERlY2VtYmVyIDE4LCAyMDE2IDg6MDkgQU08 YnI+DQo8Yj5Ubzo8L2I+IEhvc25pZWggUmFmaWVlPGJyPg0KPGI+Q2M6PC9iPiBTZWN1cml0eSBB cmVhIEFkdmlzb3J5IEdyb3VwPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbc2FhZ10gUXVlc3Rp b24gYWJvdXQgUEtJIC0gY2VydGlmaWNhdGUgc2VyaWFsIG51bWJlcjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpLCBIb3NuaWVoPG86cD48L286cD48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIDE4IERlYyAyMDE2LCBhdCAxNDoyMywg SG9zbmllaCBSYWZpZWUgJmx0OzxhIGhyZWY9Im1haWx0bzppZXRmQHJvemFuYWsuY29tIj5pZXRm QHJvemFuYWsuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0Ij5IZWxsbyw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij48YnI+DQpJbiBSRkMgNTI4MCwgSSBy ZWFkIHRoYXQgdGhlIGlzc3VlciBvZiB0aGUgY2VydGlmaWNhdGUsIGFzc2lnbmVkIGEgdW5pcXVl IG51bWJlciB0byBlYWNoIGNlcnRpZmljYXRlIGFuZCBjYWxsIGl0IGEgc2VyaWFsIG51bWJlci4g SSBhc3N1bWUgdGhhdCB0aGlzIHNlcmlhbCBudW1iZXIgaXMgc2VudCBieSB0aGUgQ0EgdG8gY2xp ZW50IHdoZW5ldmVyIHRoZSBjbGllbnQgYXNrcyBmb3IgdGhlIGNlcnRpZmljYXRlIG9mIHRoaXMg aW50ZXJtZWRpYXRlDQogQ0EuIDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIGlzc3VlciBv ZiB0aGUgY2VydGlmaWNhdGUgKD0gdGhlIENlcnRpZmljYXRlIEF1dGhvcml0eSkgYXNzaWducyB0 aGUgc2VyaWFsIG51bWJlciB3aGVuIGlzc3VpbmcgdGhlIGNlcnRpZmljYXRlLCB3aGV0aGVyIHRo aXMgY2VydGlmaWNhdGUgaXMgZm9yIGFuIEVuZCBFbnRpdHkgb3IgYW4gSW50ZXJtZWRpYXRlIENB LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+VGhhdCBtZWFucyB0aGUgYXR0 YWNrZXIgbWlnaHQgYmUgYWJsZSB0byBlYXZlc2Ryb3AgdGhpcyBzZXJpYWwgbnVtYmVyLiZuYnNw OyBpcyB0aGlzIGFzc3VtcHRpb24gdHJ1ZT8gdGhhdCBtZWFucyB0aGUgYXR0YWNrZXIgbWlnaHQg YmUgYWJsZSBhbHNvIHRvIHNwb29mDQogYW5kIHVzZSB0aGUgc2FtZSBzZXJpYWwgbnVtYmVyIGZv ciBpdHMgZmFrZSBDZXJ0aWZpY2F0ZS48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIHNlcmlhbCBudW1i ZXIsIGFuZCBpbmRlZWQgdGhlIGVudGlyZSBjZXJ0aWZpY2F0ZSBpcyBub3Qgc2VjcmV0IGluZm9y bWF0aW9uLiBJdCBpcyBzZW50IGluIHRoZSBjbGVhci4gVGhlcmUgbWF5IGJlIHByaXZhY3kgY29u Y2VybnMgYWJvdXQgdGhlIGNvbnRlbnQgb2Ygc29tZSBmaWVsZHMsIGJ1dCB0aGlzIGlzIGEgY2Fz ZSB3aGVyZSBwcml2YWN5IGlzIG5vdCBzZWN1cml0eS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIGF0dGFja2VyIGlzIHdlbGNvbWUgdG8g dXNlIHRoZSBzYW1lIHNlcmlhbCBudW1iZXIgb24gYSBmYWtlIGNlcnRpZmljYXRlLiBJdCBzaG91 bGQgbm90IGJlIGFibGUgdG8gZ2VuZXJhdGUgYSB2YWxpZCBzaWduYXR1cmUgb24gdGhhdCBmYWtl IGNlcnRpZmljYXRlLjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5JIGd1 ZXNzIEkgYW0gY29uZnVzZWQgaW4gc29tZSBwYXJ0IG9mIHByb2Nlc3NlcyAuLi4uIHdoYXQgaWYm bmJzcDsgdGhlIGNsaWVudCBvbmx5IGhhdmUgdGhlIGxpc3Qgb2YgdHJ1c3RlZCBhbmNob3JzIHJl Y2VpdmVkIGZyb20gcm9vdCBvciBpc3N1ZXIgQ0EgdGhhdA0KIGluY2x1ZGVzIGNlcnRpZmljYXRl IHNlcmlhbCBudW1iZXIsIGlzc3VlciBhbmQgc29tZSBvdGhlciBpbmZvcm1hdGlvbiBhcyBtZW50 aW9uZWQgaW4gdGhlIGFib3ZlIFJGQywgaG93IHdvdWxkIGJlIHRoZSBzZXJpYWwgbnVtYmVycyBw cm90ZWN0ZWQgYWdhaW5zdCBzcG9vZmluZyBhdHRhY2s/IHNwZWNpYWxseSBpZiB0aGUgY2xpZW50 IHZlcmlmaWNhdGlvbiBtZXRob2QgaXMgb25seSBiYXNlZCBvbiB0cnVzdGluZyB0aGlzIGxpc3Qg YW5kIG5vdA0KIGdvIHRocm91Z2ggYXNraW5nIHRoZSBpc3N1ZXIgdG8gZG93bmxvYWQgdGhlIGlu dGVybWVkaWF0ZSBDQSBjZXJ0aWZpY2F0ZSBmcm9tIHRoZSByZXBvc2l0b3J5Pzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Gb3IgdGhl IHJvb3QgQ0FzIHRoZXJlIGlzIG5vdCBwcm90ZWN0aW9uLiBUaGUgY2VydGlmaWNhdGVzIG9mIHRo ZSByb290IENBcyBzZXJ2ZSBvbmx5IGFzIHZlc3NlbHMgZm9yIHRoZSBwdWJsaWMga2V5IHdpdGhp biB0aGVtLiBUaGUgbGlzdCBvZiB0cnVzdGVkIENBIGlzIHBhcnQgb2YgdGhlIGNvbmZpZ3VyYXRp b24gb2YgYSBSZWx5aW5nIFBhcnR5LiAmbmJzcDtUaGUgc2VyaWFsIG51bWJlcnMgaW4gb3RoZXIg Y2VydGlmaWNhdGUNCiBhcmUgcGFydCBvZiB0aGUgdGJzQ2VydGlmaWNhdGUgc3RydWN0dXJlIChz ZWN0aW9uIDQuMS4xLjEpIGFuZCBhcmUgdGh1cyBwcm90ZWN0ZWQgYnkgdGhlIHNpZ25hdHVyZS4m bmJzcDs8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5EYXZpZCZndDsgU3BlY2lm aWNhbGx5LCB0aGUgdHJ1c3QgYW5jaG9yIGluY2x1ZGVzIHRoZSBpc3N1ZXLigJlzIHB1YmxpYyBr ZXksIHdoaWNoIGlzIHdoeSB0aGUgYXR0YWNrZXIgY2Fu4oCZdCBnZW5lcmF0ZSBhIHZhbGlkIHNp Z25hdHVyZSBldmVuIGlmIHNoZSB1c2VzIHRoZSBzYW1lDQogc2VyaWFsIG51bWJlciBpbiBoZXIg ZmFrZSBjZXJ0aWZpY2F0ZSAtIHNoZSBkb2VzbuKAmXQgaGF2ZSB0aGUgaXNzdWVy4oCZcyBwcml2 YXRlIGtleS4mbmJzcDsgQWxzbywgY2xpZW50IHZlcmlmaWNhdGlvbiBpbnZvbHZlcyBhIGxvdCBt b3JlIHRoYW4ganVzdCBjaGVja2luZyB0aGUgc2VyaWFsIG51bWJlciAtIHNlZSB0aGUgQ2VydGlm aWNhdGUgUGF0aCBWYWxpZGF0aW9uIGFsZ29yaXRobSBpbiBTZWN0aW9uIDYgb2YgUkZDIDUyODAg LSBldmVyeXRoaW5nIHRoZXJlDQogbmVlZHMgdG8gYmUgZG9uZSwgYXMgc2tpcHBpbmcgc3RlcHMg dGhhdCBhcHBlYXIgdG8gYmUgaXJyZWxldmFudCByaXNrcyBpbnRyb2R1Y2luZyBzdWJ0bGUgc2Vj dXJpdHkgZmxhd3MuPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5UaGUgc2Vjb25k IHF1ZXN0aW9uIGlzIHRoYXQsIHdoZW4gcm9vdCBDQSBpcyBub3QgYWx3YXlzIG9ubGluZSwgdGhh dCBtZWFucyB0aGUgQ1JMIGxpc3QgaXMgdmFsaWQgZm9yIGEgY2VydGFpbiBwZXJpb2Qgb2YgdGlt ZS4gaWYgZHVyaW5nIHRoaXMgdGltZQ0KIGEgY2VydGlmaWNhdGUgaXMgY29tcHJvbWlzZWQsIHRo ZSByb290IG5lZWRzIHRvIHNlbmQgYSBuZXcgQ1JMIHRvIGNsaWVudHMuIEluIHRoaXMgY2FzZSwg aWYgdGhlIGF0dGFja2VyIHBlcmZvcm0mbmJzcDsgcmVwbGF5IGF0dGFjayB3aXRoIHRoZSBvbGQg bGlzdCwgaXMgdGhlcmUgYW55IGluIHVzZSBtZXRob2QgdG8gYXZvaWQgc3VjaCBhdHRhY2s/PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pk5vdCB3aXRoIENSTHMuIEFuZCB5b3UgZG9u4oCZdCBuZWVkIGFuIGF0dGFjayBlaXRoZXIuIElm IEkgaGF2ZSBqdXN0IGZldGNoZWQgYSBDUkwgZm9yIHdoaWNoIHRoZSBuZXh0VXBkYXRlIGZpZWxk IGlzIEphbnVhcnkgMXN0IDIwMTcsIEkgYW0gYWxsb3dlZCB0byBjYWNoZSBpdCB1bnRpbCB0aGVu LiBBbnkgY29tcHJvbWlzZSB0aGF0IGhhcHBlbnMgaW4gdGhhdCB0aW1lIOKAlCBJIHdvbuKAmXQg a25vdyBhYm91dCBpdCB1bnRpbA0KIEphbnVhcnkgMXN0LiBBbmQgdGhpcyBpcyB0cnVlIGV2ZW4g d2l0aCBubyBDQSBkb3dudGltZS4gQWRkIENBIGRvd250aW1lLCBhbmQgSSBtaWdodCB1c2UgdGhl IGNhY2hlZCBDUkwgbG9uZ2VyLiBUaGUgQ0EgZG9lcyBub3QgYWN0aXZlbHkgc2VuZCBmcmVzaCBD UkxzIHRvIHJlbHlpbmcgcGFydGllcy4gSXQgd2FpdHMgZm9yIHRoZW0uPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9DU1AgdXN1YWxseSBoYXMg c2hvcnRlciB2YWxpZGl0eSBwZXJpb2RzLCBidXQgdGhlIG1lY2hhbmlzbSBpcyB0aGUgc2FtZS4g VGhlIHJlbHlpbmcgcGFydHkgaXMgYWxsb3dlZCB0byBjYWNoZSB0aGUgcmVzcG9uc2VzIHVudGls IHRoZSBuZXh0VXBkYXRlIHRpbWUuPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQiPkkgd291bGQgYXBwcmVjaWF0ZSBpZiBzb21lb25lIGNhbiBjbGFyaWZ5IHRoZXNlIGNhc2Vz IG9yIHBvaW50IG1lIHRvIHRoZSByaWdodCBSRkMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgZG9u4oCZdCBrbm93IHRoYXQgdGhl cmXigJlzIGFueXRoaW5nIHRoYXQgZXhwbGFpbnMgdGhpcyBiZXlvbmQgNTI4MC48c3BhbiBzdHls ZT0iY29sb3I6IzFGNDk3RCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Zb2F2PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_CE03DB3D7B45C245BCA0D243277949362F797437MX307CL04corpem_-- From nobody Mon Dec 19 07:57:05 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01731129B7A for ; Mon, 19 Dec 2016 07:57:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UUXniu4Qpuzm for ; Mon, 19 Dec 2016 07:57:02 -0800 (PST) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [IPv6:2a01:e0c:1:1599::15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05DFF129B8C for ; Mon, 19 Dec 2016 07:57:02 -0800 (PST) Received: from [192.168.0.13] (unknown [88.182.125.39]) by smtp6-g21.free.fr (Postfix) with ESMTP id 68D507803C2 for ; Mon, 19 Dec 2016 16:56:59 +0100 (CET) To: saag@ietf.org References: <39ed344a-2f66-5898-6c99-368779c8bb73@rozanak.com> From: Denis Message-ID: <4b9fb7e3-44d0-4450-f20d-175c14443455@free.fr> Date: Mon, 19 Dec 2016 16:57:03 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------12BEF2C3B5AFA6FBEB9A769C" Archived-At: Subject: Re: [saag] Question about PKI - certificate serial number X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2016 15:57:05 -0000 This is a multi-part message in MIME format. --------------12BEF2C3B5AFA6FBEB9A769C Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Hi Hosnieh, Some more details about your sentence: The second question is that, when root CA is not always online, that means the CRL list is valid for a certain period of time. If during this time a certificate is compromised, the root needs to send a new CRL to clients. In this case, if the attacker perform replay attack with the old list, is there any in use method to avoid such attack? Replay of an old CRL may only be mitigated by using a short validity period of the CRL, e.g. one day or half a day. Root CAs are most of the case managed off-line. About ten years ago, it was common to have one CRL generated once a year and hence it was valid during one full year. Some RP implementations were keeping such CRLs during one year in their caches and were not even trying to see if an emergency CRL had been issued before the end of the CRL validity period. Deleting the cache every day at night time is a good practice, and will force the fetch of a new CRL. However, this practice, AFAIK, is written nowhere. During the last ten years, some off-line root CAs are being managed a little better. They issue a CRL that is valid only during one day and these root CAs are still working off-line. How is it possible ? CRLs are generated in advance once a year and these (365) CRLs are kept in a directory. Once a day, the appropriate CRL is pushed into a DMZ and then becomes publicly accessible. If a sub-CA gets revoked, all the previously issued CRLs are suppressed and a new set of CRLs is issued. Denis > Hi, Hosnieh > > On 18 Dec 2016, at 14:23, Hosnieh Rafiee > wrote: >> >> Hello, >> >> >> In RFC 5280, I read that the issuer of the certificate, assigned a >> unique number to each certificate and call it a serial number. I >> assume that this serial number is sent by the CA to client whenever >> the client asks for the certificate of this intermediate CA. >> > The issuer of the certificate (= the Certificate Authority) assigns > the serial number when issuing the certificate, whether this > certificate is for an End Entity or an Intermediate CA. >> >> That means the attacker might be able to eavesdrop this serial >> number. is this assumption true? that means the attacker might be >> able also to spoof and use the same serial number for its fake >> Certificate. >> > The serial number, and indeed the entire certificate is not secret > information. It is sent in the clear. There may be privacy concerns > about the content of some fields, but this is a case where privacy is > not security. > > The attacker is welcome to use the same serial number on a fake > certificate. It should not be able to generate a valid signature on > that fake certificate. >> >> I guess I am confused in some part of processes .... what if the >> client only have the list of trusted anchors received from root or >> issuer CA that includes certificate serial number, issuer and some >> other information as mentioned in the above RFC, how would be the >> serial numbers protected against spoofing attack? specially if the >> client verification method is only based on trusting this list and >> not go through asking the issuer to download the intermediate CA >> certificate from the repository? >> > For the root CAs there is not protection. The certificates of the root > CAs serve only as vessels for the public key within them. The list of > trusted CA is part of the configuration of a Relying Party. The > serial numbers in other certificate are part of the tbsCertificate > structure (section 4.1.1.1) and are thus protected by the signature. >> >> The second question is that, when root CA is not always online, that >> means the CRL list is valid for a certain period of time. if during >> this time a certificate is compromised, the root needs to send a new >> CRL to clients. In this case, if the attacker perform replay attack >> with the old list, is there any in use method to avoid such attack? >> > Not with CRLs. And you don’t need an attack either. If I have just > fetched a CRL for which the nextUpdate field is January 1st 2017, I am > allowed to cache it until then. Any compromise that happens in that > time — I won’t know about it until January 1st. And this is true even > with no CA downtime. Add CA downtime, and I might use the cached CRL > longer. The CA does not actively send fresh CRLs to relying parties. > It waits for them. > > OCSP usually has shorter validity periods, but the mechanism is the > same. The relying party is allowed to cache the responses until the > nextUpdate time. >> >> I would appreciate if someone can clarify these cases or point me to >> the right RFC. >> > I don’t know that there’s anything that explains this beyond 5280. > > Yoav > > > > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag --------------12BEF2C3B5AFA6FBEB9A769C Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Hi Hosnieh,

Some more details about your sentence:
The second question is that, when root CA is not always online, that means the CRL list is valid for a certain period of time.
If during this time a certificate is compromised, the root needs to send a new CRL to clients. In this case, if the attacker perform
replay attack with the old list, is there any in use method to avoid such attack?
Replay of an old CRL may only be mitigated by using a short validity period of the CRL, e.g. one day or half a day.
Root CAs are most of the case managed off-line. About ten years ago, it was common to have one CRL generated once a year
and hence it was valid during one full year.

Some RP implementations were keeping such CRLs during one year in their caches and were not even trying to see if an emergency CRL had been issued
before the end of the CRL validity period. Deleting the cache every day at night time is a good practice, and will force the fetch of a new CRL.
However, this practice, AFAIK,  is written nowhere.

During the last ten years, some off-line root CAs are being managed a little better. They issue a CRL that is valid only during one day and these root CAs
are still working off-line. How is it possible ?

CRLs are generated in advance once a year and these (365) CRLs are kept in a directory. Once a day, the appropriate CRL is pushed
into a DMZ and then becomes publicly accessible. If a sub-CA gets revoked, all the previously issued CRLs are suppressed and a new set of CRLs
is issued.

Denis

Hi, Hosnieh

On 18 Dec 2016, at 14:23, Hosnieh Rafiee <ietf@rozanak.com> wrote:

Hello,


In RFC 5280, I read that the issuer of the certificate, assigned a unique number to each certificate and call it a serial number. I assume that this serial number is sent by the CA to client whenever the client asks for the certificate of this intermediate CA.

The issuer of the certificate (= the Certificate Authority) assigns the serial number when issuing the certificate, whether this certificate is for an End Entity or an Intermediate CA.

That means the attacker might be able to eavesdrop this serial number.  is this assumption true? that means the attacker might be able also to spoof and use the same serial number for its fake Certificate.

The serial number, and indeed the entire certificate is not secret information. It is sent in the clear. There may be privacy concerns about the content of some fields, but this is a case where privacy is not security.

The attacker is welcome to use the same serial number on a fake certificate. It should not be able to generate a valid signature on that fake certificate.

I guess I am confused in some part of processes .... what if  the client only have the list of trusted anchors received from root or issuer CA that includes certificate serial number, issuer and some other information as mentioned in the above RFC, how would be the serial numbers protected against spoofing attack? specially if the client verification method is only based on trusting this list and not go through asking the issuer to download the intermediate CA certificate from the repository?

For the root CAs there is not protection. The certificates of the root CAs serve only as vessels for the public key within them. The list of trusted CA is part of the configuration of a Relying Party.  The serial numbers in other certificate are part of the tbsCertificate structure (section 4.1.1.1) and are thus protected by the signature. 

The second question is that, when root CA is not always online, that means the CRL list is valid for a certain period of time. if during this time a certificate is compromised, the root needs to send a new CRL to clients. In this case, if the attacker perform  replay attack with the old list, is there any in use method to avoid such attack?

Not with CRLs. And you don’t need an attack either. If I have just fetched a CRL for which the nextUpdate field is January 1st 2017, I am allowed to cache it until then. Any compromise that happens in that time — I won’t know about it until January 1st. And this is true even with no CA downtime. Add CA downtime, and I might use the cached CRL longer. The CA does not actively send fresh CRLs to relying parties. It waits for them.

OCSP usually has shorter validity periods, but the mechanism is the same. The relying party is allowed to cache the responses until the nextUpdate time.

I would appreciate if someone can clarify these cases or point me to the right RFC.

I don’t know that there’s anything that explains this beyond 5280.

Yoav




_______________________________________________
saag mailing list
saag@ietf.org
https://www.ietf.org/mailman/listinfo/saag


--------------12BEF2C3B5AFA6FBEB9A769C-- From nobody Sat Dec 31 13:31:46 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8BF31294AE for ; Sat, 31 Dec 2016 13:31:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J-QAvff7-3pW for ; Sat, 31 Dec 2016 13:31:44 -0800 (PST) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0093.outbound.protection.outlook.com [104.47.40.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2C281294A3 for ; Sat, 31 Dec 2016 13:31:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=QAQciHgG2AyrGZUP9KBurGNabZwfNjy89pTZ1533X5o=; b=cAVTQoHaX5TL5E2J92KPF9uIIa6Ej0bcpqdOgngIMDKYoP7NA+2i4xmFpB4TCOwt7m79OCCGAtY+Gleva3tPQqoW4j2PQarKmEzAaormz/xkeTyL7PgQVx0IGNVQ5DIzXteZe7HFTKobMmJRQMKwCZEr+puFRFlEZt2fsx4o1Ug= Received: from BN3PR03MB2355.namprd03.prod.outlook.com (10.166.74.150) by BN3PR03MB2353.namprd03.prod.outlook.com (10.166.74.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.803.11; Sat, 31 Dec 2016 21:31:41 +0000 Received: from BN3PR03MB2355.namprd03.prod.outlook.com ([10.166.74.150]) by BN3PR03MB2355.namprd03.prod.outlook.com ([10.166.74.150]) with mapi id 15.01.0803.021; Sat, 31 Dec 2016 21:31:41 +0000 From: Mike Jones To: "saag@ietf.org" Thread-Topic: Using RSA Algorithms with COSE Messages Thread-Index: AdJjpEu8Y3CnLIB3RHKvk1NTw30gZgACHsYQ Date: Sat, 31 Dec 2016 21:31:41 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [50.47.95.25] x-ms-office365-filtering-correlation-id: 21331bda-8141-4f7e-3c84-08d431c46942 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:BN3PR03MB2353; x-microsoft-exchange-diagnostics: 1; BN3PR03MB2353; 7:lX8mYVWMPtPZFE0P3c5tahUVqon3a21QBeTa/ZrxPVVlV8pJjp+LuJhapgLDXzzZ5hg4XiI1q98GMsTDnjGxvrSo2FNuB9ocz+92E3AqMQ/ow0LqJGkXlY/hC+OZYdsFB7p7aYE3OJy1f1N1rvl/gfpvepXnDc3ujqzoFXYkLZhkfVbmm7BdlP6MhDEqdIdo7vbsYtmWNMvnTjOx3Yk4Jkfo3LtK45vD3hiUUMz4/eI9uJGSeLSxIJJeHoE3GescP0M2KacAqEwitwBxHN9cGOoixxSEcZ043IPkgWUhd+PqDWXv4sgoYLpc9N/RXgwPYFVcLal7uHjFTHDrxythttMLhO3CdZajNaqAjyvqFYljMaViUvoWtHIan4yFt3P11cvBvBisd8KjYY72WhoidVVsb/aQuz1eKzZehphA/xqCL02jNoGMIXIzkZLyiWrtagM2q+fmZoY1qYh5E915zAnXxM1mDvBiQYGISvjMSmA= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705)(31418570063057)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123562025)(20161123560025)(20161123564025)(20161123555025)(6047074)(6042181)(6072148); SRVR:BN3PR03MB2353; BCL:0; PCL:0; RULEID:; SRVR:BN3PR03MB2353; x-forefront-prvs: 0173C6D4D5 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(209900001)(199003)(377454003)(189002)(2473002)(5660300001)(68736007)(106356001)(6506006)(10290500002)(110136003)(38730400001)(33656002)(2900100001)(7696004)(8990500004)(3660700001)(5640700003)(2420400007)(229853002)(74316002)(66066001)(2950100002)(15650500001)(92566002)(105586002)(99286003)(6916009)(2351001)(6436002)(606005)(7906003)(25786008)(2501003)(77096006)(7736002)(55016002)(107886002)(7110500001)(790700001)(8676002)(50986999)(76176999)(5630700001)(10090500001)(54356999)(97736004)(86612001)(102836003)(81166006)(8936002)(122556002)(3280700002)(450100001)(5005710100001)(6116002)(9686002)(86362001)(3846002)(189998001)(101416001)(1730700003)(2906002)(81156014)(6606295002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR03MB2353; H:BN3PR03MB2355.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN3PR03MB23554D0DE31D0EA00C155744F56D0BN3PR03MB2355namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Dec 2016 21:31:41.3150 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR03MB2353 Archived-At: Subject: [saag] FW: Using RSA Algorithms with COSE Messages X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Dec 2016 21:31:45 -0000 --_000_BN3PR03MB23554D0DE31D0EA00C155744F56D0BN3PR03MB2355namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Bringing to SAAG's attention as well... From: COSE [mailto:cose-bounces@ietf.org] On Behalf Of Mike Jones Sent: Saturday, December 31, 2016 1:28 PM To: cose@ietf.org Subject: [COSE] Using RSA Algorithms with COSE Messages The specification Using RSA Algorithms with COSE Messages defines encodings for using RSA algorit= hms with CBOR Object Signing and Encryption (COSE) messages. This supports use cases for the FIDO= Alliance and others that need this functionality. Security Area Director = Kathleen Moriarty has agreed to AD sponsorship of this specification. This= specification incorporates text from draft-ietf-cose-msg-05 - the last COS= E specification version before the RSA algorithms were removed. The specification is available at: * https://tools.ietf.org/html/draft-jones-cose-rsa-01 An HTML-formatted version is also available at: * http://self-issued.info/docs/draft-jones-cose-rsa-01.html Review feedback is welcomed! -- Mike P.S. This notice was also posted at http://self-issued.info/?p=3D1624 and = as @selfissued. --_000_BN3PR03MB23554D0DE31D0EA00C155744F56D0BN3PR03MB2355namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Bringing to SAAG’= ;s attention as well…

 

From: COSE [mailto:cose-bounces@ietf.org] = On Behalf Of Mike Jones
Sent: Saturday, December 31, 2016 1:28 PM
To: cose@ietf.org
Subject: [COSE] Using RSA Algorithms with COSE Messages

 

The specification Using RSA Algorithms with COSE Messages defines encodings for using RSA= algorithms with CBOR Object = Signing and Encryption (COSE) messages.  This supports use cases f= or the FIDO Alliance and others that need this functionality.  Securit= y Area Director Kathleen Moriarty has agreed to AD sponsorship of this specification.  This specification incorpor= ates text from draft-ietf-cose-msg-05 – the last COSE specification v= ersion before the RSA algorithms were removed.

 

The specification is available at:

  • <= a href=3D"https://tools.ietf.org/html/draft-jones-cose-rsa-01">https://tool= s.ietf.org/html/draft-jones-cose-rsa-01

 

An HTML-formatted version is also available at:=

  • <= a href=3D"http://self-issued.info/docs/draft-jones-cose-rsa-01.html">http:/= /self-issued.info/docs/draft-jones-cose-rsa-01.html

    •  

    Review feedback is welcomed!

     

            &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;        -- Mike

     

    P.S.  This notice was also posted at http://self-issued.info/?p=3D1624 and as @selfissued.

--_000_BN3PR03MB23554D0DE31D0EA00C155744F56D0BN3PR03MB2355namp_--