From dan.winship@gmail.com Mon May 3 14:03:42 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5EB823A6AE4 for ; Mon, 3 May 2010 14:03:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.317 X-Spam-Level: X-Spam-Status: No, score=0.317 tagged_above=-999 required=5 tests=[AWL=-0.018, BAYES_50=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z421w1SEPvwV for ; Mon, 3 May 2010 14:03:41 -0700 (PDT) Received: from mysterion.org (mysterion.org [69.25.196.35]) by core3.amsl.com (Postfix) with ESMTP id 40A023A695A for ; Mon, 3 May 2010 14:03:31 -0700 (PDT) Received: from desktop.home.mysterion.org (c-76-97-71-164.hsd1.ga.comcast.net [76.97.71.164]) by mysterion.org (Postfix) with ESMTPA id EA591802AE; Mon, 3 May 2010 17:03:16 -0400 (EDT) Message-ID: <4BDF3A10.2050005@gmail.com> Date: Mon, 03 May 2010 17:03:12 -0400 From: Dan Winship User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100413 Fedora/3.0.4-2.fc13 Thunderbird/3.0.4 MIME-Version: 1.0 To: Peter Saint-Andre References: <4BDB4D73.2050405@stpeter.im> In-Reply-To: <4BDB4D73.2050405@stpeter.im> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: certid@ietf.org Subject: Re: [certid] BCP on SSL/TLS certificates X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 May 2010 21:03:42 -0000 The ordering rules in 3.2 contain a paradox: o Reference identifiers that include the source domain MUST be preferred over reference identifiers that include a target domain (if any). ... o A reference identifier of type CN-ID (if included) MUST always be the lowest-priority reference identifier in the list. So in the example given, the CN-ID MUST be 3rd by the former rule, and MUST be 5th by latter rule. -- Dan From stpeter@stpeter.im Mon May 3 14:16:49 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFF023A695A for ; Mon, 3 May 2010 14:16:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.382 X-Spam-Level: X-Spam-Status: No, score=-1.382 tagged_above=-999 required=5 tests=[AWL=-0.642, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EZ4DEGFmGJwu for ; Mon, 3 May 2010 14:16:48 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 259183A6B13 for ; Mon, 3 May 2010 14:16:47 -0700 (PDT) Received: from dhcp-64-101-72-158.cisco.com (dhcp-64-101-72-158.cisco.com [64.101.72.158]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id D645C40E16; Mon, 3 May 2010 15:16:32 -0600 (MDT) Message-ID: <4BDF3D2F.3080800@stpeter.im> Date: Mon, 03 May 2010 15:16:31 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Dan Winship References: <4BDB4D73.2050405@stpeter.im> <4BDF3A10.2050005@gmail.com> In-Reply-To: <4BDF3A10.2050005@gmail.com> X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090005030908070101020805" Cc: certid@ietf.org Subject: Re: [certid] BCP on SSL/TLS certificates X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 May 2010 21:16:49 -0000 This is a cryptographically signed message in MIME format. --------------ms090005030908070101020805 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 5/3/10 3:03 PM, Dan Winship wrote: > The ordering rules in 3.2 contain a paradox: >=20 > o Reference identifiers that include the source domain MUST be > preferred over reference identifiers that include a target domain= > (if any). >=20 > ... >=20 > o A reference identifier of type CN-ID (if included) MUST always be= > the lowest-priority reference identifier in the list. >=20 > So in the example given, the CN-ID MUST be 3rd by the former rule, and > MUST be 5th by latter rule. Good point. We'll fix that in the next version (probably by saying that, notwithstanding all other ordering rules, a CN-ID must never be ranked higher than any other identifier type). Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms090005030908070101020805 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWnDCC B1cwggY/oAMCAQICAVUwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQTAeFw0wOTA3MDYwMDAwMDFaFw0xMDA3MDYyMzU5NTlaMIHCMQswCQYDVQQG EwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEiMCAGA1UEChMZWE1Q UCBTdGFuZGFyZHMgRm91bmRhdGlvbjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0 aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcN AQkBFhJzdHBldGVyQHN0cGV0ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCas7Mrnh02GakN8sft+HJpU4MwBxEgrGDZ2ZzUxDDt2sEhM+9Q74h955MtgMhK3TeBf6Hs hDh/8Z9G//k2qNA0M2S5rejTqrmW0Jabca/L7BUZ0GhnU2N/2zeciFUmuZ4A2l1T5IMX2ZVP XnNIaefBtbImJAbDz3T0vxkzTtcqgW3wL83PMDiqiuM+e1k+VPvOW4f5ZSGkPIhYCDpWqNE5 wZvjrLNMc8jZOPs9DrsYuIVwU72Vhy1tkEh+w6YpYHrdEUAe+eKe6TuxqZ60e9z3O36uiV// Ms274iD6PbA/IGazJgaAdg6tvPehwTYGJAGmv3PsJKkLGjgoh+RrrM1LAgMBAAGjggOKMIID hjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFOyws3XWgIY9FP1POVqjdZP9Lu38MB0GA1UdEQQWMBSBEnN0cGV0ZXJA c3RwZXRlci5pbTCBqAYDVR0jBIGgMIGdgBR7iZySlyShhEcCy3T8LvSs3DLl86GBgaR/MH0x CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eYIBDzCCAUcGA1UdIASCAT4wggE6MIIBNgYLKwYBBAGBtTcBAgAw ggElMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQG CCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG8 BggrBgEFBQcCAjCBrzAUFg1TdGFydENvbSBMdGQuMAMCAQEagZZMaW1pdGVkIExpYWJpbGl0 eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENv bSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTMtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczMvY2xpZW50L2NhMEIGCCsGAQUFBzAC hjZodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MzLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUA A4IBAQBgv4xFXZqDKSOtnPOVbqOh1brj7oxRaVYk7N0MJG7x9Y/wkO3iwRwizVLcC1bA+D/R gyFilXx6IQWE63Ge2tu+Y4w5QoHYwuUFQuBZuxvZpOa3ykdgPlBQaBM8m+Ien0skwNggaizA X9Pc/sMLpP3jkO1iSF4agy4r5Ed+4G10mP5X0zO3gQwq9Uj4F9tX+58kU+fM1P8Sh+BYR4r/ kSbKE3tWcMaKblWPGwX0nYD26Je7Qb+uX/J5lCgozBrHXQWq8N98iklASf2pv+32Oi1dEjmM UgAm/J2+YmxaI02+c+H6QH8+F3RUjCiRg9XqUNjcrNrnTFnm/iMMZADktsXPMIIHVzCCBj+g AwIBAgIBVTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBMB4XDTA5MDcwNjAwMDAwMVoXDTEwMDcwNjIzNTk1OVowgcIxCzAJBgNVBAYTAlVTMREw DwYDVQQIEwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMSIwIAYDVQQKExlYTVBQIFN0YW5k YXJkcyBGb3VuZGF0aW9uMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0 cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJqzsyue HTYZqQ3yx+34cmlTgzAHESCsYNnZnNTEMO3awSEz71DviH3nky2AyErdN4F/oeyEOH/xn0b/ +Tao0DQzZLmt6NOquZbQlptxr8vsFRnQaGdTY3/bN5yIVSa5ngDaXVPkgxfZlU9ec0hp58G1 siYkBsPPdPS/GTNO1yqBbfAvzc8wOKqK4z57WT5U+85bh/llIaQ8iFgIOlao0TnBm+Oss0xz yNk4+z0Ouxi4hXBTvZWHLW2QSH7Dpilget0RQB754p7pO7GpnrR73Pc7fq6JX/8yzbviIPo9 sD8gZrMmBoB2Dq2896HBNgYkAaa/c+wkqQsaOCiH5GuszUsCAwEAAaOCA4owggOGMAkGA1Ud EwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNV HQ4EFgQU7LCzddaAhj0U/U85WqN1k/0u7fwwHQYDVR0RBBYwFIESc3RwZXRlckBzdHBldGVy LmltMIGoBgNVHSMEgaAwgZ2AFHuJnJKXJKGERwLLdPwu9KzcMuXzoYGBpH8wfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5ggEPMIIBRwYDVR0gBIIBPjCCATowggE2BgsrBgEEAYG1NwECADCCASUwLgYI KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUH AgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbwGCCsGAQUF BwICMIGvMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBlkxpbWl0ZWQgTGlhYmlsaXR5LCByZWFk IHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9j cnR1My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2Nz cC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNV HRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAGC/ jEVdmoMpI62c85Vuo6HVuuPujFFpViTs3QwkbvH1j/CQ7eLBHCLNUtwLVsD4P9GDIWKVfHoh BYTrcZ7a275jjDlCgdjC5QVC4Fm7G9mk5rfKR2A+UFBoEzyb4h6fSyTA2CBqLMBf09z+wwuk /eOQ7WJIXhqDLivkR37gbXSY/lfTM7eBDCr1SPgX21f7nyRT58zU/xKH4FhHiv+RJsoTe1Zw xopuVY8bBfSdgPbol7tBv65f8nmUKCjMGsddBarw33yKSUBJ/am/7fY6LV0SOYxSACb8nb5i bFojTb5z4fpAfz4XdFSMKJGD1epQ2Nys2udMWeb+IwxkAOS2xc8wggfiMIIFyqADAgECAgEP MA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQD EyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAzMzJaFw0x MjEwMjIyMTAzMzJaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC5o0luEj4gypQIp71Xi2TlXyLYrj9WkRy+d9BO 0FHPYnAsC99/jx/ibNRwIfAoFhZd+LDscdRSckvwuFSz0bKg3z+9o7cwlVAC9AwMWe8IM0Lx c+8etYxsX4WIamG9fjzzi5GAW5ESKzzIN3SxHSplyGCWFwx/pgf1f4y6O9/ym+4f6zaDYP6B x0r+SaJcr6eSGNm7X3EwX1v7XpRBY+aw019o7k72d0IX910F+XGt0OwNdM61Ff3FiTiexeUZ bWxCGm6GZl+SQVG9xYVIgHQaLXoQF+g2wzrmKCbVcZhqH+hrlRnD6PfCuEyX/BR6PlAPRDlQ 6f1u3wqik+LF5P15AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAd BgNVHQ4EFgQUe4mckpckoYRHAst0/C70rNwy5fMwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UX aYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UE AxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9Bggr BgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2Et Y3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYD VR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQg Q29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCBy ZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIB DQRDFkFTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVt YWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAUpcEDdsKFRCxFBxcSm+8oMTT fpS7fbZkxWHx5fHDjvAgaBQ+oY0tk4xtbD6VxeHYjxI63+hj8jICnqeVXPe34Bu+XzekIn2T lrnPCQobKdQF2p52QgUvIxSURed0jcBaCBV22DSKaUqDOzD/Tx6VQy78zpblXjRH7OALE/+H jzJVmspdnBUUtQOLYgPo924xkxR25VDdgtEE5vAXa/g2oCeZhy0ZEO4NbgIayAYCJcJRDz0h dD2Ahec65Kw6LB3N7VXEjiRR5/WoKwH/QteRzPJbFDc1somrApjm2cyg+5nbm1RHeFIz+GxX luRrPztvhNcby0PtAjqwY1txi4sW0R6ZJPuZ2DZ1/dzckoFhyZgFyOX3SEkNXVLldjTzneFJ FnVSzDbc720vq184jR7pYoI9+f5QJ96a0iLxEAG8SJ5auBwXI/w2FmKmwmdMvJ8/17+B4sMC IRrXrDQl2xzpVXh/Qcmk5nf+w8HFmqATGy1OUAQbXga7AySAUaYhvvFk50u0bO5DiUGwzrJO 3TrwvaC2Ei4EFaBmIVgG7TfU5TaaY9IcJSCQ7AGUYE3RFSRpsLOoA3DsxP42YERgS/Nxw29+ YqZtPoO2QPbNpI7xnHVCfNBabx3oDIf438nFfv8spw5BQqBSbEF1izJA57eE64CzHnt7lB20 OFD11avYopwxggPKMIIDxgIBATCBkjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBAgFVMAkGBSsOAwIaBQCgggIMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTEwMDUwMzIxMTYzMVowIwYJKoZIhvcNAQkEMRYEFGCUvUg9sx2XKGlYrUUb fXqRzC6SMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAQdTSfnF0E7ttIOx6vOnEgBAaKZuGGc3iuslS3Jsn wtL8RzAWXoWOu3kb7RIfB07shm8tdwfPfXdGtCfliIMx25OJiuiTUBQ6RlDlP0ZklvuFzuTb okPvapg4KHUhDErutZIA01ldoNxBNL09tBxYM81uvfgdNuuAdJiAx+7NeDdKTXYrRkeWTaXB TQo4yoMFxAcq7DmkvE797f/aZ10DdmnebpQ4V3YfSYalgL8Wi3y3rp9A3TshsPoYZw0Maume zibfXdai4j01LvHtZx391J9bEV8Nxn7FPTnTwXoQp/rSgdA73HBiMT6VR0MvWV6AR4QaSwLm 7SA9Qo3EeoeNRgAAAAAAAA== --------------ms090005030908070101020805-- From mrex@sap.com Tue May 11 15:47:51 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82E403A6940 for ; Tue, 11 May 2010 15:47:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.765 X-Spam-Level: X-Spam-Status: No, score=-7.765 tagged_above=-999 required=5 tests=[AWL=-0.116, BAYES_50=0.001, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22la80t+6la7 for ; Tue, 11 May 2010 15:47:44 -0700 (PDT) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id AA5363A6858 for ; Tue, 11 May 2010 15:47:43 -0700 (PDT) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id o4BMlVtp007747 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 12 May 2010 00:47:31 +0200 (MEST) From: Martin Rex Message-Id: <201005112247.o4BMlUH3011595@fs4113.wdf.sap.corp> To: certid@ietf.org Date: Wed, 12 May 2010 00:47:30 +0200 (MEST) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal08 X-SAP: out Subject: Re: [certid] Comments on draft-saintandre-tls-server-id-check-03 X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 May 2010 22:47:51 -0000 Jeff Hodges wrote: > > > The various standards for translating a DER encoded Name into > > a string call for the RDNs to be ordered, left to right, from > > most specific to most general, the reverse of the order in which > > they appear in the DER encoded certificate. > > AFAICT, there is only one clear non-implementation-specific > specification for a X.500/LDAP DN string representation, > and that's (now) RFC4514 (obsoletes 2253, which obsoleted 1779, > which obsoleted 1485). Is there a DN string rep specified > anywhere in the ISO specs (I can't find one)? The description above oversimplifies the process. In ASN.1 a distinguished name is a sequence of RDNames, which are sets of attribute-value pairs. Often these sets only contain a single attribute value pair, but they _can_ contain several attribute value pairs, and some CA software seems to stuff serialNumber and CN into a single RDName set. The result is a little weird. Multiple attribute-value pairs in a set are glued together with a plus (+) sign instead of a comma (,) and the original ordering of the set is retained! (where as the ordering of the RDName elements is reversed). Further complicating the issue: While DER encoding leaves the ordering of the contents of an ASN.1 SEQUENCE as is, the ordering of the contents of an ASN.1 SET is "canonicalized" by DER encoding (based on the numeric ordering of the final binary encoding of each element). So the shorter elements will always end up first in RDNames containing multiple attribute-value pairs in a SET. i.e. CN=Foo+2.5.4.5=123ABC,O=bar,C=ZZ 2.5.4.5=227DEF+CN=LongName,O=bar,C=ZZ Btw. the XMLdsig guys actually recommend an additional restriction on top of rfc4514: http://www.w3.org/TR/xmldsig-core/#dname-encrules One area that may create slight interop problems with some legacy software is the printable attribute label used for certain attributes. rfc4514 SN= 2.5.4.surname(4) 2.5.4.5= 2.5.4.serialNumber(5) ST= 2.5.4.stateOrProvince(8) The string representation also does not carry through the "simple type" used in the original ASN.1 DER encoding (like PrintableString,IA5String,UTF8String,BMPString). -Martin From Jeff.Hodges@KingsMountain.com Tue May 11 16:47:57 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE1053A6929 for ; Tue, 11 May 2010 16:47:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.258 X-Spam-Level: X-Spam-Status: No, score=0.258 tagged_above=-999 required=5 tests=[AWL=-0.077, BAYES_50=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CUzMdC5G-V04 for ; Tue, 11 May 2010 16:47:56 -0700 (PDT) Received: from outbound-mail-313.bluehost.com (cpoproxy3-pub.bluehost.com [67.222.54.6]) by core3.amsl.com (Postfix) with SMTP id 7BD5E3A6822 for ; Tue, 11 May 2010 16:47:56 -0700 (PDT) Received: (qmail 13161 invoked by uid 0); 11 May 2010 23:47:46 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by cpoproxy3.bluehost.com with SMTP; 11 May 2010 23:47:46 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kingsmountain.com; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=vxukeAgtQ1jkDl/YlZA+s9fAIr3do8xe84VwgLDr/UJRH/77I5c6pSGPyMsywVHGVY8tY66LwV0hwQliYc1i/Gmv1OzaV8Kk1rVEqkg9kQky/Rn1uRql1ZVmhxaN+Q94; Received: from c-67-161-32-29.hsd1.ca.comcast.net ([67.161.32.29] helo=[192.168.11.11]) by box514.bluehost.com with esmtpsa (SSLv3:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1OBzAv-0006u6-LX; Tue, 11 May 2010 17:47:45 -0600 Message-ID: <4BE9EC9F.9030903@KingsMountain.com> Date: Tue, 11 May 2010 16:47:43 -0700 From: =JeffH User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: IETF cert-based identity , Martin Rex Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 67.161.32.29 authed with jeff.hodges+kingsmountain.com} Subject: Re: [certid] Comments on draft-saintandre-tls-server-id-check-03 X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 May 2010 23:47:57 -0000 > Jeff Hodges wrote: >> >> > The various standards for translating a DER encoded Name into >> > a string call for the RDNs to be ordered, left to right, from >> > most specific to most general, the reverse of the order in which >> > they appear in the DER encoded certificate. >> >> AFAICT, there is only one clear non-implementation-specific >> specification for a X.500/LDAP DN string representation, >> and that's (now) RFC4514 (obsoletes 2253, which obsoleted 1779, >> which obsoleted 1485). Is there a DN string rep specified >> anywhere in the ISO specs (I can't find one)? > > The description above oversimplifies the process. > > In ASN.1 a distinguished name is a sequence of RDNames, which are > sets of attribute-value pairs. Often these sets only contain a > single attribute value pair, but they _can_ contain several > attribute value pairs, and some CA software seems to stuff > serialNumber and CN into a single RDName set. Thanks very much for this detailed heads-up. > The result is a little weird. Multiple attribute-value pairs > in a set are glued together with a plus (+) sign instead of a > comma (,) and the original ordering of the set is retained! Ah, this (i.e. "the result") would be the resultant DN string representation as spec'd by RFC4514 section 2.2. > Further complicating the issue: While DER encoding leaves the ordering > of the contents of an ASN.1 SEQUENCE as is, the ordering of the contents > of an ASN.1 SET is "canonicalized" by DER encoding (based on the > numeric ordering of the final binary encoding of each element). > So the shorter elements will always end up first in RDNames > containing multiple attribute-value pairs in a SET. > > i.e. > > CN=Foo+2.5.4.5=123ABC,O=bar,C=ZZ > 2.5.4.5=227DEF+CN=LongName,O=bar,C=ZZ Ok, thx, good catch. AFAICT, this revelation means we have some re-working to do to -tls-server-id-check in sections 2.1 and 3.1.3 in order to denote that RDNs can contain a set of AVAs. > Btw. the XMLdsig guys actually recommend an additional restriction > on top of rfc4514: > > http://www.w3.org/TR/xmldsig-core/#dname-encrules this item seems to be an escaping of (apparent) ASCII control chars when rendering a DER encoded DN as a DN string representation, yes? And it is a MAY-level requirement in the XMLdsig spec. > One area that may create slight interop problems with some legacy software > is the printable attribute label used for certain attributes. > > rfc4514 > SN= 2.5.4.surname(4) > 2.5.4.5= 2.5.4.serialNumber(5) > ST= 2.5.4.stateOrProvince(8) Ok, although I'm unsure how this might affect the -tls-server-id-check spec. thanks again, =JeffH From stpeter@stpeter.im Wed May 12 08:45:30 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 13CFA3A6CD2 for ; Wed, 12 May 2010 08:45:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.155 X-Spam-Level: X-Spam-Status: No, score=-1.155 tagged_above=-999 required=5 tests=[AWL=-0.415, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n09BkVmveb0o for ; Wed, 12 May 2010 08:45:28 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 024A73A6DB4 for ; Wed, 12 May 2010 08:35:13 -0700 (PDT) Received: from leavealone.cisco.com (72-163-0-129.cisco.com [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 2FCD540D06; Wed, 12 May 2010 09:35:02 -0600 (MDT) Message-ID: <4BEACAA4.1080402@stpeter.im> Date: Wed, 12 May 2010 09:35:00 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: =JeffH References: <4BE9EC9F.9030903@KingsMountain.com> In-Reply-To: <4BE9EC9F.9030903@KingsMountain.com> X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms000209050203020200090208" Cc: IETF cert-based identity Subject: Re: [certid] Comments on draft-saintandre-tls-server-id-check-03 X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2010 15:45:30 -0000 This is a cryptographically signed message in MIME format. --------------ms000209050203020200090208 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 5/11/10 5:47 PM, =3DJeffH wrote: >> Jeff Hodges wrote: >>> >>> > The various standards for translating a DER encoded Name into >>> > a string call for the RDNs to be ordered, left to right, from >>> > most specific to most general, the reverse of the order in which >>> > they appear in the DER encoded certificate. >>> >>> AFAICT, there is only one clear non-implementation-specific >>> specification for a X.500/LDAP DN string representation, >>> and that's (now) RFC4514 (obsoletes 2253, which obsoleted 1779, >>> which obsoleted 1485). Is there a DN string rep specified >>> anywhere in the ISO specs (I can't find one)? >> >> The description above oversimplifies the process. >> >> In ASN.1 a distinguished name is a sequence of RDNames, which are >> sets of attribute-value pairs. Often these sets only contain a >> single attribute value pair, but they _can_ contain several >> attribute value pairs, and some CA software seems to stuff >> serialNumber and CN into a single RDName set. >=20 > Thanks very much for this detailed heads-up. >=20 >=20 >> The result is a little weird. Multiple attribute-value pairs >> in a set are glued together with a plus (+) sign instead of a >> comma (,) and the original ordering of the set is retained! >=20 > Ah, this (i.e. "the result") would be the resultant DN string > representation as spec'd by RFC4514 section 2.2. >=20 >=20 >> Further complicating the issue: While DER encoding leaves the ordering= >> of the contents of an ASN.1 SEQUENCE as is, the ordering of the conten= ts >> of an ASN.1 SET is "canonicalized" by DER encoding (based on the >> numeric ordering of the final binary encoding of each element). >> So the shorter elements will always end up first in RDNames >> containing multiple attribute-value pairs in a SET. >> >> i.e. >> >> CN=3DFoo+2.5.4.5=3D123ABC,O=3Dbar,C=3DZZ >> 2.5.4.5=3D227DEF+CN=3DLongName,O=3Dbar,C=3DZZ >=20 > Ok, thx, good catch. >=20 > AFAICT, this revelation means we have some re-working to do to > -tls-server-id-check in sections 2.1 and 3.1.3 in order to denote that > RDNs can contain a set of AVAs. Is this text more accurate? The subject field of a PKIX certificate is defined as a X.501 type Name and known as a Distinguished Name (DN) -- see [X.501] and [PKIX]. A DN is an ordered sequence of Relative Distinguished Name (RDNs), where an RDN is a set (i.e., an unordered group) of type-and- value pairs [LDAP-DN], each of which asserts some attribute about the subject of the certificate. Where [LDAP-DN] =3D RFC 4514 and [PKIX] =3D RFC 5280. BTW I don't see any evidence for the following claim in RFC 4514: The RDNs are ordered in the DN sequence from most general to most specific. Corrections welcome. Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms000209050203020200090208 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWnDCC B1cwggY/oAMCAQICAVUwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQTAeFw0wOTA3MDYwMDAwMDFaFw0xMDA3MDYyMzU5NTlaMIHCMQswCQYDVQQG EwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEiMCAGA1UEChMZWE1Q UCBTdGFuZGFyZHMgRm91bmRhdGlvbjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0 aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcN AQkBFhJzdHBldGVyQHN0cGV0ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCas7Mrnh02GakN8sft+HJpU4MwBxEgrGDZ2ZzUxDDt2sEhM+9Q74h955MtgMhK3TeBf6Hs hDh/8Z9G//k2qNA0M2S5rejTqrmW0Jabca/L7BUZ0GhnU2N/2zeciFUmuZ4A2l1T5IMX2ZVP XnNIaefBtbImJAbDz3T0vxkzTtcqgW3wL83PMDiqiuM+e1k+VPvOW4f5ZSGkPIhYCDpWqNE5 wZvjrLNMc8jZOPs9DrsYuIVwU72Vhy1tkEh+w6YpYHrdEUAe+eKe6TuxqZ60e9z3O36uiV// Ms274iD6PbA/IGazJgaAdg6tvPehwTYGJAGmv3PsJKkLGjgoh+RrrM1LAgMBAAGjggOKMIID hjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFOyws3XWgIY9FP1POVqjdZP9Lu38MB0GA1UdEQQWMBSBEnN0cGV0ZXJA c3RwZXRlci5pbTCBqAYDVR0jBIGgMIGdgBR7iZySlyShhEcCy3T8LvSs3DLl86GBgaR/MH0x CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eYIBDzCCAUcGA1UdIASCAT4wggE6MIIBNgYLKwYBBAGBtTcBAgAw ggElMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQG CCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG8 BggrBgEFBQcCAjCBrzAUFg1TdGFydENvbSBMdGQuMAMCAQEagZZMaW1pdGVkIExpYWJpbGl0 eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENv bSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTMtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczMvY2xpZW50L2NhMEIGCCsGAQUFBzAC hjZodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MzLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUA A4IBAQBgv4xFXZqDKSOtnPOVbqOh1brj7oxRaVYk7N0MJG7x9Y/wkO3iwRwizVLcC1bA+D/R gyFilXx6IQWE63Ge2tu+Y4w5QoHYwuUFQuBZuxvZpOa3ykdgPlBQaBM8m+Ien0skwNggaizA X9Pc/sMLpP3jkO1iSF4agy4r5Ed+4G10mP5X0zO3gQwq9Uj4F9tX+58kU+fM1P8Sh+BYR4r/ kSbKE3tWcMaKblWPGwX0nYD26Je7Qb+uX/J5lCgozBrHXQWq8N98iklASf2pv+32Oi1dEjmM UgAm/J2+YmxaI02+c+H6QH8+F3RUjCiRg9XqUNjcrNrnTFnm/iMMZADktsXPMIIHVzCCBj+g AwIBAgIBVTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBMB4XDTA5MDcwNjAwMDAwMVoXDTEwMDcwNjIzNTk1OVowgcIxCzAJBgNVBAYTAlVTMREw DwYDVQQIEwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMSIwIAYDVQQKExlYTVBQIFN0YW5k YXJkcyBGb3VuZGF0aW9uMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0 cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJqzsyue HTYZqQ3yx+34cmlTgzAHESCsYNnZnNTEMO3awSEz71DviH3nky2AyErdN4F/oeyEOH/xn0b/ +Tao0DQzZLmt6NOquZbQlptxr8vsFRnQaGdTY3/bN5yIVSa5ngDaXVPkgxfZlU9ec0hp58G1 siYkBsPPdPS/GTNO1yqBbfAvzc8wOKqK4z57WT5U+85bh/llIaQ8iFgIOlao0TnBm+Oss0xz yNk4+z0Ouxi4hXBTvZWHLW2QSH7Dpilget0RQB754p7pO7GpnrR73Pc7fq6JX/8yzbviIPo9 sD8gZrMmBoB2Dq2896HBNgYkAaa/c+wkqQsaOCiH5GuszUsCAwEAAaOCA4owggOGMAkGA1Ud EwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNV HQ4EFgQU7LCzddaAhj0U/U85WqN1k/0u7fwwHQYDVR0RBBYwFIESc3RwZXRlckBzdHBldGVy LmltMIGoBgNVHSMEgaAwgZ2AFHuJnJKXJKGERwLLdPwu9KzcMuXzoYGBpH8wfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5ggEPMIIBRwYDVR0gBIIBPjCCATowggE2BgsrBgEEAYG1NwECADCCASUwLgYI KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUH AgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbwGCCsGAQUF BwICMIGvMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBlkxpbWl0ZWQgTGlhYmlsaXR5LCByZWFk IHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9j cnR1My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2Nz cC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNV HRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAGC/ jEVdmoMpI62c85Vuo6HVuuPujFFpViTs3QwkbvH1j/CQ7eLBHCLNUtwLVsD4P9GDIWKVfHoh BYTrcZ7a275jjDlCgdjC5QVC4Fm7G9mk5rfKR2A+UFBoEzyb4h6fSyTA2CBqLMBf09z+wwuk /eOQ7WJIXhqDLivkR37gbXSY/lfTM7eBDCr1SPgX21f7nyRT58zU/xKH4FhHiv+RJsoTe1Zw xopuVY8bBfSdgPbol7tBv65f8nmUKCjMGsddBarw33yKSUBJ/am/7fY6LV0SOYxSACb8nb5i bFojTb5z4fpAfz4XdFSMKJGD1epQ2Nys2udMWeb+IwxkAOS2xc8wggfiMIIFyqADAgECAgEP MA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQD EyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAzMzJaFw0x MjEwMjIyMTAzMzJaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC5o0luEj4gypQIp71Xi2TlXyLYrj9WkRy+d9BO 0FHPYnAsC99/jx/ibNRwIfAoFhZd+LDscdRSckvwuFSz0bKg3z+9o7cwlVAC9AwMWe8IM0Lx c+8etYxsX4WIamG9fjzzi5GAW5ESKzzIN3SxHSplyGCWFwx/pgf1f4y6O9/ym+4f6zaDYP6B x0r+SaJcr6eSGNm7X3EwX1v7XpRBY+aw019o7k72d0IX910F+XGt0OwNdM61Ff3FiTiexeUZ bWxCGm6GZl+SQVG9xYVIgHQaLXoQF+g2wzrmKCbVcZhqH+hrlRnD6PfCuEyX/BR6PlAPRDlQ 6f1u3wqik+LF5P15AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAd BgNVHQ4EFgQUe4mckpckoYRHAst0/C70rNwy5fMwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UX aYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UE AxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9Bggr BgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2Et Y3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYD VR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQg Q29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCBy ZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIB DQRDFkFTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVt YWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAUpcEDdsKFRCxFBxcSm+8oMTT fpS7fbZkxWHx5fHDjvAgaBQ+oY0tk4xtbD6VxeHYjxI63+hj8jICnqeVXPe34Bu+XzekIn2T lrnPCQobKdQF2p52QgUvIxSURed0jcBaCBV22DSKaUqDOzD/Tx6VQy78zpblXjRH7OALE/+H jzJVmspdnBUUtQOLYgPo924xkxR25VDdgtEE5vAXa/g2oCeZhy0ZEO4NbgIayAYCJcJRDz0h dD2Ahec65Kw6LB3N7VXEjiRR5/WoKwH/QteRzPJbFDc1somrApjm2cyg+5nbm1RHeFIz+GxX luRrPztvhNcby0PtAjqwY1txi4sW0R6ZJPuZ2DZ1/dzckoFhyZgFyOX3SEkNXVLldjTzneFJ FnVSzDbc720vq184jR7pYoI9+f5QJ96a0iLxEAG8SJ5auBwXI/w2FmKmwmdMvJ8/17+B4sMC IRrXrDQl2xzpVXh/Qcmk5nf+w8HFmqATGy1OUAQbXga7AySAUaYhvvFk50u0bO5DiUGwzrJO 3TrwvaC2Ei4EFaBmIVgG7TfU5TaaY9IcJSCQ7AGUYE3RFSRpsLOoA3DsxP42YERgS/Nxw29+ YqZtPoO2QPbNpI7xnHVCfNBabx3oDIf438nFfv8spw5BQqBSbEF1izJA57eE64CzHnt7lB20 OFD11avYopwxggPKMIIDxgIBATCBkjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBAgFVMAkGBSsOAwIaBQCgggIMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTEwMDUxMjE1MzUwMFowIwYJKoZIhvcNAQkEMRYEFHr082aU0Pw+IsgZs7cB XF7bHLooMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAcNiApHkze7f2D7F1KUPc8/TuBag7Kz97Uo/W7nrd kNNNu5gjXIMEuz+psEh0Rm/A6z5BuSfvAlcc3FdbfNNrIgU3G5SthlCGPNMtc2yg3xE3/+0V Lg4ZhKK/rMj0mANpLsO+qHBszcjTijKqIeywd9B+f3+WM+vdJQsC+vahMlfqL00rlYLohw17 YvrWcXHhP3dYX/31ktYctPDCsH0OLpGhVMKFTRe3ikcNDHbAr5bpF0DrvOw8q8GqNu60RHsO Krja+G2/BXcroKMUX9xvGroi89fAkhfYkBm+Bq7BLzwfVpECx4l0gzp7dbBnELK8G9FndVjk 9d+mF4xNbVnyQwAAAAAAAA== --------------ms000209050203020200090208-- From Jeff.Hodges@KingsMountain.com Wed May 12 13:30:08 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 768123A6937 for ; Wed, 12 May 2010 13:30:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.546 X-Spam-Level: X-Spam-Status: No, score=-0.546 tagged_above=-999 required=5 tests=[AWL=-0.881, BAYES_50=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XQV-3xYc4pJB for ; Wed, 12 May 2010 13:30:04 -0700 (PDT) Received: from outbound-mail-313.bluehost.com (cpoproxy3-pub.bluehost.com [67.222.54.6]) by core3.amsl.com (Postfix) with SMTP id E65123A6924 for ; Wed, 12 May 2010 13:30:03 -0700 (PDT) Received: (qmail 1997 invoked by uid 0); 12 May 2010 20:29:54 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by cpoproxy3.bluehost.com with SMTP; 12 May 2010 20:29:53 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kingsmountain.com; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=TzQDuJiNd6yX8NDmLhbjPtilUZerc8iBCzkDMPk2uYVLhP1e9Hno5UMNnrPNn5Ct2cwnLA24L8Zt4b7wjkoDGets+UMSqErYDpzIP7xXyOp1XVuldFqdGbHHb8GbDJpu; Received: from outbound4.ebay.com ([216.113.168.128] helo=[10.244.49.154]) by box514.bluehost.com with esmtpsa (SSLv3:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1OCIYz-0003Cz-Dl for certid@ietf.org; Wed, 12 May 2010 14:29:53 -0600 Message-ID: <4BEB0FBF.5070502@KingsMountain.com> Date: Wed, 12 May 2010 13:29:51 -0700 From: =JeffH User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: IETF cert-based identity Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 216.113.168.128 authed with jeff.hodges+kingsmountain.com} Subject: Re: [certid] Comments on draft-saintandre-tls-server-id-check-03 X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2010 20:30:08 -0000 > Is this text more accurate? > > The subject field of a PKIX certificate is defined as a X.501 type > Name and known as a Distinguished Name (DN) -- see [X.501] and > [PKIX]. A DN is an ordered sequence of Relative Distinguished Name > (RDNs), where an RDN is a set (i.e., an unordered group) of type-and- > value pairs [LDAP-DN], each of which asserts some attribute about the > subject of the certificate. yes, IMV. > BTW I don't see any evidence for the following claim in RFC 4514: > > The RDNs are ordered in the DN sequence from > most general to most specific. It is in X.501 (V3 (4th edition) section 9.7).. The distinguished name of a given object is defined as that name which consists of the sequence of the RDNs of the entry which represents the object and those of all of its superior entries (in descending order). However, various (many? most?) CAs don't have an actual X.500 / LDAP directory with actual entries for the subjects of the certs they issue, and so concoct their subjectName DNs outta thin air (more or less) and so the notion that the RDNs in such DNs are ordered from most general to most specific doesn't necessarily hold (from what I understand). So I'm not sure right now what to say about that. I suspect we can still stipulate that the only RDN having attr type of CN that we'll pay attention to is the one at the far end of the RDN sequence comprising the DN. =JeffH From turners@ieca.com Wed May 12 14:36:35 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33D783A691E for ; Wed, 12 May 2010 14:36:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.67 X-Spam-Level: X-Spam-Status: No, score=-0.67 tagged_above=-999 required=5 tests=[AWL=-0.672, BAYES_50=0.001, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yCM0MnH3XDgA for ; Wed, 12 May 2010 14:36:33 -0700 (PDT) Received: from smtp111.biz.mail.re2.yahoo.com (smtp111.biz.mail.re2.yahoo.com [66.196.116.96]) by core3.amsl.com (Postfix) with SMTP id B7EB53A6876 for ; Wed, 12 May 2010 14:36:33 -0700 (PDT) Received: (qmail 99821 invoked from network); 12 May 2010 21:36:21 -0000 Received: from thunderfish.local (turners@96.231.119.54 with plain) by smtp111.biz.mail.re2.yahoo.com with SMTP; 12 May 2010 14:36:20 -0700 PDT X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: PciQKCsVM1kZDKHZNbO_ZU1A9pejYBc_bjf6HnuSb0rdknCcRY.mx5LW8huXz2JuVKhfErrW.jkw6_pWUPcpacbU6wLHuTEro93puMXVeNHe3NRkQIrI8edY5T9.gmc_b1njXFE8JshtKL4vksxxoVqdFE_A6qkGXQp.bZHoGdfu.OlXLls7_PoLDnbhT4bmflwVJ33o_T0faDv7hOD4.8JVbhxUUVhgBfTQ7LS2xrTGdO79VX5fSKzj2f70XXb46r7iVta.YWeQZhGpVGwhvICQjv2899_SeIowonUmfUva5ieiWXodu64OgyK080OAIXxh62C44AL6k1umQTmYR.kxaNvdFNkkxFKd47GnCTPmhYHXVwiPPj1CkKSnSLT1vqIkhCdmnEqpIWYCITsdysdPTCmnEaqanwR6Yx1BoT_UDUy1FhMZDjbc3mR4GdDLzcCClmH5aHdS2k_QheYr9y2uDA-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4BEB1F54.2060905@ieca.com> Date: Wed, 12 May 2010 17:36:20 -0400 From: Sean Turner User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: =JeffH References: <4BEB0FBF.5070502@KingsMountain.com> In-Reply-To: <4BEB0FBF.5070502@KingsMountain.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF cert-based identity Subject: Re: [certid] Comments on draft-saintandre-tls-server-id-check-03 X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2010 21:36:35 -0000 =JeffH wrote: > > Is this text more accurate? > > > > The subject field of a PKIX certificate is defined as a X.501 type > > Name and known as a Distinguished Name (DN) -- see [X.501] and > > [PKIX]. A DN is an ordered sequence of Relative Distinguished Name > > (RDNs), where an RDN is a set (i.e., an unordered group) of type-and- > > value pairs [LDAP-DN], each of which asserts some attribute about the > > subject of the certificate. > > yes, IMV. > > > > BTW I don't see any evidence for the following claim in RFC 4514: > > > > The RDNs are ordered in the DN sequence from > > most general to most specific. > > It is in X.501 (V3 (4th edition) section 9.7).. > > The distinguished name of a given object is defined as that name which > consists of the sequence of the RDNs of the entry which represents the > object and those of all of its superior entries (in descending order). > > > However, various (many? most?) CAs don't have an actual X.500 / LDAP > directory with actual entries for the subjects of the certs they issue, > and so concoct their subjectName DNs outta thin air (more or less) and > so the notion that the RDNs in such DNs are ordered from most general to > most specific doesn't necessarily hold (from what I understand). > > So I'm not sure right now what to say about that. I suspect we can still > stipulate that the only RDN having attr type of CN that we'll pay > attention to is the one at the far end of the RDN sequence comprising > the DN. I think a lot of DNs got concocted because X.500 implementers assumed the examples in X.501 were normative. That is c=, o=, (4) ou=, cn=. But, you're might be right about no descending ordering can be assumed. If you look at the subjectName in the datatracker certificate it's: CN = *.ietf.org OU = Terms of use at www.verisign.com/rpa (c)05 OU = Internet Engineering Task Force O = IETF Trust L = Reston ST = Virginia C = US Is an organization more or less specific than a location? spt From stpeter@stpeter.im Wed May 12 15:37:04 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 631123A67F6 for ; Wed, 12 May 2010 15:37:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.917 X-Spam-Level: X-Spam-Status: No, score=-1.917 tagged_above=-999 required=5 tests=[AWL=0.682, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28Px8rGW2vd7 for ; Wed, 12 May 2010 15:37:03 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id D59A73A6800 for ; Wed, 12 May 2010 15:37:01 -0700 (PDT) Received: from leavealone.cisco.com (72-163-0-129.cisco.com [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 2C08240D06 for ; Wed, 12 May 2010 16:36:51 -0600 (MDT) Message-ID: <4BEB2D80.8070203@stpeter.im> Date: Wed, 12 May 2010 16:36:48 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: certid@ietf.org References: <4BEB0FBF.5070502@KingsMountain.com> <4BEB1F54.2060905@ieca.com> In-Reply-To: <4BEB1F54.2060905@ieca.com> X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms080607010902060507090406" Subject: Re: [certid] Comments on draft-saintandre-tls-server-id-check-03 X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2010 22:37:04 -0000 This is a cryptographically signed message in MIME format. --------------ms080607010902060507090406 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 5/12/10 3:36 PM, Sean Turner wrote: > I think a lot of DNs got concocted because X.500 implementers assumed > the examples in X.501 were normative. That is c=3D, o=3D, (4) ou=3D, c= n=3D. > But, you're might be right about no descending ordering can be assumed.= =20 > If you look at the subjectName in the datatracker certificate it's: >=20 > CN =3D *.ietf.org > OU =3D Terms of use at www.verisign.com/rpa (c)05 > OU =3D Internet Engineering Task Force > O =3D IETF Trust > L =3D Reston > ST =3D Virginia > C =3D US >=20 > Is an organization more or less specific than a location? The Internet encompasses all locations, so in this case C =3D US is much more specific than OU =3D Internet Engineering Task Force. ;) --------------ms080607010902060507090406 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWnDCC B1cwggY/oAMCAQICAVUwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQTAeFw0wOTA3MDYwMDAwMDFaFw0xMDA3MDYyMzU5NTlaMIHCMQswCQYDVQQG EwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEiMCAGA1UEChMZWE1Q UCBTdGFuZGFyZHMgRm91bmRhdGlvbjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0 aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcN AQkBFhJzdHBldGVyQHN0cGV0ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCas7Mrnh02GakN8sft+HJpU4MwBxEgrGDZ2ZzUxDDt2sEhM+9Q74h955MtgMhK3TeBf6Hs hDh/8Z9G//k2qNA0M2S5rejTqrmW0Jabca/L7BUZ0GhnU2N/2zeciFUmuZ4A2l1T5IMX2ZVP XnNIaefBtbImJAbDz3T0vxkzTtcqgW3wL83PMDiqiuM+e1k+VPvOW4f5ZSGkPIhYCDpWqNE5 wZvjrLNMc8jZOPs9DrsYuIVwU72Vhy1tkEh+w6YpYHrdEUAe+eKe6TuxqZ60e9z3O36uiV// Ms274iD6PbA/IGazJgaAdg6tvPehwTYGJAGmv3PsJKkLGjgoh+RrrM1LAgMBAAGjggOKMIID hjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFOyws3XWgIY9FP1POVqjdZP9Lu38MB0GA1UdEQQWMBSBEnN0cGV0ZXJA c3RwZXRlci5pbTCBqAYDVR0jBIGgMIGdgBR7iZySlyShhEcCy3T8LvSs3DLl86GBgaR/MH0x CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eYIBDzCCAUcGA1UdIASCAT4wggE6MIIBNgYLKwYBBAGBtTcBAgAw ggElMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQG CCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG8 BggrBgEFBQcCAjCBrzAUFg1TdGFydENvbSBMdGQuMAMCAQEagZZMaW1pdGVkIExpYWJpbGl0 eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENv bSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTMtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczMvY2xpZW50L2NhMEIGCCsGAQUFBzAC hjZodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MzLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUA A4IBAQBgv4xFXZqDKSOtnPOVbqOh1brj7oxRaVYk7N0MJG7x9Y/wkO3iwRwizVLcC1bA+D/R gyFilXx6IQWE63Ge2tu+Y4w5QoHYwuUFQuBZuxvZpOa3ykdgPlBQaBM8m+Ien0skwNggaizA X9Pc/sMLpP3jkO1iSF4agy4r5Ed+4G10mP5X0zO3gQwq9Uj4F9tX+58kU+fM1P8Sh+BYR4r/ kSbKE3tWcMaKblWPGwX0nYD26Je7Qb+uX/J5lCgozBrHXQWq8N98iklASf2pv+32Oi1dEjmM UgAm/J2+YmxaI02+c+H6QH8+F3RUjCiRg9XqUNjcrNrnTFnm/iMMZADktsXPMIIHVzCCBj+g AwIBAgIBVTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBMB4XDTA5MDcwNjAwMDAwMVoXDTEwMDcwNjIzNTk1OVowgcIxCzAJBgNVBAYTAlVTMREw DwYDVQQIEwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMSIwIAYDVQQKExlYTVBQIFN0YW5k YXJkcyBGb3VuZGF0aW9uMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0 cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJqzsyue HTYZqQ3yx+34cmlTgzAHESCsYNnZnNTEMO3awSEz71DviH3nky2AyErdN4F/oeyEOH/xn0b/ +Tao0DQzZLmt6NOquZbQlptxr8vsFRnQaGdTY3/bN5yIVSa5ngDaXVPkgxfZlU9ec0hp58G1 siYkBsPPdPS/GTNO1yqBbfAvzc8wOKqK4z57WT5U+85bh/llIaQ8iFgIOlao0TnBm+Oss0xz yNk4+z0Ouxi4hXBTvZWHLW2QSH7Dpilget0RQB754p7pO7GpnrR73Pc7fq6JX/8yzbviIPo9 sD8gZrMmBoB2Dq2896HBNgYkAaa/c+wkqQsaOCiH5GuszUsCAwEAAaOCA4owggOGMAkGA1Ud EwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNV HQ4EFgQU7LCzddaAhj0U/U85WqN1k/0u7fwwHQYDVR0RBBYwFIESc3RwZXRlckBzdHBldGVy LmltMIGoBgNVHSMEgaAwgZ2AFHuJnJKXJKGERwLLdPwu9KzcMuXzoYGBpH8wfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5ggEPMIIBRwYDVR0gBIIBPjCCATowggE2BgsrBgEEAYG1NwECADCCASUwLgYI KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUH AgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbwGCCsGAQUF BwICMIGvMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBlkxpbWl0ZWQgTGlhYmlsaXR5LCByZWFk IHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9j cnR1My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2Nz cC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNV HRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAGC/ jEVdmoMpI62c85Vuo6HVuuPujFFpViTs3QwkbvH1j/CQ7eLBHCLNUtwLVsD4P9GDIWKVfHoh BYTrcZ7a275jjDlCgdjC5QVC4Fm7G9mk5rfKR2A+UFBoEzyb4h6fSyTA2CBqLMBf09z+wwuk /eOQ7WJIXhqDLivkR37gbXSY/lfTM7eBDCr1SPgX21f7nyRT58zU/xKH4FhHiv+RJsoTe1Zw xopuVY8bBfSdgPbol7tBv65f8nmUKCjMGsddBarw33yKSUBJ/am/7fY6LV0SOYxSACb8nb5i bFojTb5z4fpAfz4XdFSMKJGD1epQ2Nys2udMWeb+IwxkAOS2xc8wggfiMIIFyqADAgECAgEP MA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQD EyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAzMzJaFw0x MjEwMjIyMTAzMzJaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC5o0luEj4gypQIp71Xi2TlXyLYrj9WkRy+d9BO 0FHPYnAsC99/jx/ibNRwIfAoFhZd+LDscdRSckvwuFSz0bKg3z+9o7cwlVAC9AwMWe8IM0Lx c+8etYxsX4WIamG9fjzzi5GAW5ESKzzIN3SxHSplyGCWFwx/pgf1f4y6O9/ym+4f6zaDYP6B x0r+SaJcr6eSGNm7X3EwX1v7XpRBY+aw019o7k72d0IX910F+XGt0OwNdM61Ff3FiTiexeUZ bWxCGm6GZl+SQVG9xYVIgHQaLXoQF+g2wzrmKCbVcZhqH+hrlRnD6PfCuEyX/BR6PlAPRDlQ 6f1u3wqik+LF5P15AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAd BgNVHQ4EFgQUe4mckpckoYRHAst0/C70rNwy5fMwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UX aYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UE AxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9Bggr BgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2Et Y3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYD VR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQg Q29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCBy ZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIB DQRDFkFTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVt YWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAUpcEDdsKFRCxFBxcSm+8oMTT fpS7fbZkxWHx5fHDjvAgaBQ+oY0tk4xtbD6VxeHYjxI63+hj8jICnqeVXPe34Bu+XzekIn2T lrnPCQobKdQF2p52QgUvIxSURed0jcBaCBV22DSKaUqDOzD/Tx6VQy78zpblXjRH7OALE/+H jzJVmspdnBUUtQOLYgPo924xkxR25VDdgtEE5vAXa/g2oCeZhy0ZEO4NbgIayAYCJcJRDz0h dD2Ahec65Kw6LB3N7VXEjiRR5/WoKwH/QteRzPJbFDc1somrApjm2cyg+5nbm1RHeFIz+GxX luRrPztvhNcby0PtAjqwY1txi4sW0R6ZJPuZ2DZ1/dzckoFhyZgFyOX3SEkNXVLldjTzneFJ FnVSzDbc720vq184jR7pYoI9+f5QJ96a0iLxEAG8SJ5auBwXI/w2FmKmwmdMvJ8/17+B4sMC IRrXrDQl2xzpVXh/Qcmk5nf+w8HFmqATGy1OUAQbXga7AySAUaYhvvFk50u0bO5DiUGwzrJO 3TrwvaC2Ei4EFaBmIVgG7TfU5TaaY9IcJSCQ7AGUYE3RFSRpsLOoA3DsxP42YERgS/Nxw29+ YqZtPoO2QPbNpI7xnHVCfNBabx3oDIf438nFfv8spw5BQqBSbEF1izJA57eE64CzHnt7lB20 OFD11avYopwxggPKMIIDxgIBATCBkjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBAgFVMAkGBSsOAwIaBQCgggIMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTEwMDUxMjIyMzY0OFowIwYJKoZIhvcNAQkEMRYEFNX9hhmIfsq2mALR1Egi 2ZCZ3q1TMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEABOZC88kVm7HnuzcLmcU62gNq2kXa0lZtZ6Ei8rmP 26RSaL7cSJv5a1LIrakRsyavwVJEVmjKdGeUQIF7Vn/9EiBjuq/wHaGprbWlcAqyqrWeh0Rg 30+5L/IvLKXM/sSVDLR5KzTodnKYfmZnRzF/R4yXkYexJ0W4cSwbD4dilcvrowb6hHERnQSI phzCZWAb2Qr4x1O5qOaC20u12KjJjxrLrGcMQ93eBsFY3T9Le7z3mtsslrAXsBDdOSaJx0VC JV2LFjZeRLdEu7+7c9KKa336Isi7jOZ2qm6OKNXfWfxWdnBTlJMLQXtIG76xhC1hvjKE2pg6 TUNKV/vHp2UfuwAAAAAAAA== --------------ms080607010902060507090406-- From stpeter@stpeter.im Wed May 12 15:38:27 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F05EC3A6960 for ; Wed, 12 May 2010 15:38:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.952 X-Spam-Level: X-Spam-Status: No, score=-1.952 tagged_above=-999 required=5 tests=[AWL=0.647, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H6bqSGX-pq6E for ; Wed, 12 May 2010 15:38:26 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 766E53A69C6 for ; Wed, 12 May 2010 15:38:10 -0700 (PDT) Received: from leavealone.cisco.com (72-163-0-129.cisco.com [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 0564A40D06 for ; Wed, 12 May 2010 16:37:59 -0600 (MDT) Message-ID: <4BEB2DC7.5020409@stpeter.im> Date: Wed, 12 May 2010 16:37:59 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: certid@ietf.org References: <4BEB0FBF.5070502@KingsMountain.com> In-Reply-To: <4BEB0FBF.5070502@KingsMountain.com> X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms010502010400020402070302" Subject: Re: [certid] Comments on draft-saintandre-tls-server-id-check-03 X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2010 22:38:28 -0000 This is a cryptographically signed message in MIME format. --------------ms010502010400020402070302 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 5/12/10 2:29 PM, =3DJeffH wrote: >> Is this text more accurate? >> >> The subject field of a PKIX certificate is defined as a X.501 type >> Name and known as a Distinguished Name (DN) -- see [X.501] and >> [PKIX]. A DN is an ordered sequence of Relative Distinguished Name= >> (RDNs), where an RDN is a set (i.e., an unordered group) of type-an= d- >> value pairs [LDAP-DN], each of which asserts some attribute about t= he >> subject of the certificate. >=20 > yes, IMV. Good. >> BTW I don't see any evidence for the following claim in RFC 4514: >> >> The RDNs are ordered in the DN sequence from >> most general to most specific. >=20 > It is in X.501 (V3 (4th edition) section 9.7).. >=20 > The distinguished name of a given object is defined as that name whic= h > consists of the sequence of the RDNs of the entry which represents th= e > object and those of all of its superior entries (in descending order)= =2E >=20 >=20 > However, various (many? most?) CAs don't have an actual X.500 / LDAP > directory with actual entries for the subjects of the certs they issue,= > and so concoct their subjectName DNs outta thin air (more or less) and > so the notion that the RDNs in such DNs are ordered from most general t= o > most specific doesn't necessarily hold (from what I understand). >=20 > So I'm not sure right now what to say about that. I suspect we can stil= l > stipulate that the only RDN having attr type of CN that we'll pay > attention to is the one at the far end of the RDN sequence comprising > the DN. We can stipulate that, but is it realistic? Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms010502010400020402070302 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWnDCC B1cwggY/oAMCAQICAVUwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQTAeFw0wOTA3MDYwMDAwMDFaFw0xMDA3MDYyMzU5NTlaMIHCMQswCQYDVQQG EwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEiMCAGA1UEChMZWE1Q UCBTdGFuZGFyZHMgRm91bmRhdGlvbjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0 aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcN AQkBFhJzdHBldGVyQHN0cGV0ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCas7Mrnh02GakN8sft+HJpU4MwBxEgrGDZ2ZzUxDDt2sEhM+9Q74h955MtgMhK3TeBf6Hs hDh/8Z9G//k2qNA0M2S5rejTqrmW0Jabca/L7BUZ0GhnU2N/2zeciFUmuZ4A2l1T5IMX2ZVP XnNIaefBtbImJAbDz3T0vxkzTtcqgW3wL83PMDiqiuM+e1k+VPvOW4f5ZSGkPIhYCDpWqNE5 wZvjrLNMc8jZOPs9DrsYuIVwU72Vhy1tkEh+w6YpYHrdEUAe+eKe6TuxqZ60e9z3O36uiV// Ms274iD6PbA/IGazJgaAdg6tvPehwTYGJAGmv3PsJKkLGjgoh+RrrM1LAgMBAAGjggOKMIID hjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFOyws3XWgIY9FP1POVqjdZP9Lu38MB0GA1UdEQQWMBSBEnN0cGV0ZXJA c3RwZXRlci5pbTCBqAYDVR0jBIGgMIGdgBR7iZySlyShhEcCy3T8LvSs3DLl86GBgaR/MH0x CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eYIBDzCCAUcGA1UdIASCAT4wggE6MIIBNgYLKwYBBAGBtTcBAgAw ggElMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQG CCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG8 BggrBgEFBQcCAjCBrzAUFg1TdGFydENvbSBMdGQuMAMCAQEagZZMaW1pdGVkIExpYWJpbGl0 eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENv bSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTMtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczMvY2xpZW50L2NhMEIGCCsGAQUFBzAC hjZodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MzLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUA A4IBAQBgv4xFXZqDKSOtnPOVbqOh1brj7oxRaVYk7N0MJG7x9Y/wkO3iwRwizVLcC1bA+D/R gyFilXx6IQWE63Ge2tu+Y4w5QoHYwuUFQuBZuxvZpOa3ykdgPlBQaBM8m+Ien0skwNggaizA X9Pc/sMLpP3jkO1iSF4agy4r5Ed+4G10mP5X0zO3gQwq9Uj4F9tX+58kU+fM1P8Sh+BYR4r/ kSbKE3tWcMaKblWPGwX0nYD26Je7Qb+uX/J5lCgozBrHXQWq8N98iklASf2pv+32Oi1dEjmM UgAm/J2+YmxaI02+c+H6QH8+F3RUjCiRg9XqUNjcrNrnTFnm/iMMZADktsXPMIIHVzCCBj+g AwIBAgIBVTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBMB4XDTA5MDcwNjAwMDAwMVoXDTEwMDcwNjIzNTk1OVowgcIxCzAJBgNVBAYTAlVTMREw DwYDVQQIEwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMSIwIAYDVQQKExlYTVBQIFN0YW5k YXJkcyBGb3VuZGF0aW9uMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0 cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJqzsyue HTYZqQ3yx+34cmlTgzAHESCsYNnZnNTEMO3awSEz71DviH3nky2AyErdN4F/oeyEOH/xn0b/ +Tao0DQzZLmt6NOquZbQlptxr8vsFRnQaGdTY3/bN5yIVSa5ngDaXVPkgxfZlU9ec0hp58G1 siYkBsPPdPS/GTNO1yqBbfAvzc8wOKqK4z57WT5U+85bh/llIaQ8iFgIOlao0TnBm+Oss0xz yNk4+z0Ouxi4hXBTvZWHLW2QSH7Dpilget0RQB754p7pO7GpnrR73Pc7fq6JX/8yzbviIPo9 sD8gZrMmBoB2Dq2896HBNgYkAaa/c+wkqQsaOCiH5GuszUsCAwEAAaOCA4owggOGMAkGA1Ud EwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNV HQ4EFgQU7LCzddaAhj0U/U85WqN1k/0u7fwwHQYDVR0RBBYwFIESc3RwZXRlckBzdHBldGVy LmltMIGoBgNVHSMEgaAwgZ2AFHuJnJKXJKGERwLLdPwu9KzcMuXzoYGBpH8wfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5ggEPMIIBRwYDVR0gBIIBPjCCATowggE2BgsrBgEEAYG1NwECADCCASUwLgYI KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUH AgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbwGCCsGAQUF BwICMIGvMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBlkxpbWl0ZWQgTGlhYmlsaXR5LCByZWFk IHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9j cnR1My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2Nz cC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNV HRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAGC/ jEVdmoMpI62c85Vuo6HVuuPujFFpViTs3QwkbvH1j/CQ7eLBHCLNUtwLVsD4P9GDIWKVfHoh BYTrcZ7a275jjDlCgdjC5QVC4Fm7G9mk5rfKR2A+UFBoEzyb4h6fSyTA2CBqLMBf09z+wwuk /eOQ7WJIXhqDLivkR37gbXSY/lfTM7eBDCr1SPgX21f7nyRT58zU/xKH4FhHiv+RJsoTe1Zw xopuVY8bBfSdgPbol7tBv65f8nmUKCjMGsddBarw33yKSUBJ/am/7fY6LV0SOYxSACb8nb5i bFojTb5z4fpAfz4XdFSMKJGD1epQ2Nys2udMWeb+IwxkAOS2xc8wggfiMIIFyqADAgECAgEP MA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQD EyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAzMzJaFw0x MjEwMjIyMTAzMzJaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC5o0luEj4gypQIp71Xi2TlXyLYrj9WkRy+d9BO 0FHPYnAsC99/jx/ibNRwIfAoFhZd+LDscdRSckvwuFSz0bKg3z+9o7cwlVAC9AwMWe8IM0Lx c+8etYxsX4WIamG9fjzzi5GAW5ESKzzIN3SxHSplyGCWFwx/pgf1f4y6O9/ym+4f6zaDYP6B x0r+SaJcr6eSGNm7X3EwX1v7XpRBY+aw019o7k72d0IX910F+XGt0OwNdM61Ff3FiTiexeUZ bWxCGm6GZl+SQVG9xYVIgHQaLXoQF+g2wzrmKCbVcZhqH+hrlRnD6PfCuEyX/BR6PlAPRDlQ 6f1u3wqik+LF5P15AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAd BgNVHQ4EFgQUe4mckpckoYRHAst0/C70rNwy5fMwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UX aYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UE AxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9Bggr BgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2Et Y3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYD VR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQg Q29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCBy ZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIB DQRDFkFTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVt YWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAUpcEDdsKFRCxFBxcSm+8oMTT fpS7fbZkxWHx5fHDjvAgaBQ+oY0tk4xtbD6VxeHYjxI63+hj8jICnqeVXPe34Bu+XzekIn2T lrnPCQobKdQF2p52QgUvIxSURed0jcBaCBV22DSKaUqDOzD/Tx6VQy78zpblXjRH7OALE/+H jzJVmspdnBUUtQOLYgPo924xkxR25VDdgtEE5vAXa/g2oCeZhy0ZEO4NbgIayAYCJcJRDz0h dD2Ahec65Kw6LB3N7VXEjiRR5/WoKwH/QteRzPJbFDc1somrApjm2cyg+5nbm1RHeFIz+GxX luRrPztvhNcby0PtAjqwY1txi4sW0R6ZJPuZ2DZ1/dzckoFhyZgFyOX3SEkNXVLldjTzneFJ FnVSzDbc720vq184jR7pYoI9+f5QJ96a0iLxEAG8SJ5auBwXI/w2FmKmwmdMvJ8/17+B4sMC IRrXrDQl2xzpVXh/Qcmk5nf+w8HFmqATGy1OUAQbXga7AySAUaYhvvFk50u0bO5DiUGwzrJO 3TrwvaC2Ei4EFaBmIVgG7TfU5TaaY9IcJSCQ7AGUYE3RFSRpsLOoA3DsxP42YERgS/Nxw29+ YqZtPoO2QPbNpI7xnHVCfNBabx3oDIf438nFfv8spw5BQqBSbEF1izJA57eE64CzHnt7lB20 OFD11avYopwxggPKMIIDxgIBATCBkjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBAgFVMAkGBSsOAwIaBQCgggIMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTEwMDUxMjIyMzc1OVowIwYJKoZIhvcNAQkEMRYEFNhV1QywvP9701cfR+bx K7lrq1JOMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAWJOTo4Trb8LM4jtGA9xxjory0BzOSPUr+s5bTCGf VJPRg5v1A8+HqGw2SWe9x/Ky5Aow8Y85di/Y9zwNAYXfTrshWWiiAlPO0wPKAj/rvj1Jxw98 nE6fp4MSJQgQhz6/DmcykdflRNAgJT3jzWiP1JE/Dski1cCJ5c/gBQOZTJ2IvyazFpyWlWWl iROHW71Ls2tAPY4e56tJaZNWkk1eZ/jmg/yZwL3kUYaUROocChnV5gBY9B8k5jKRibGzYRJH x44pUiTckOQewf2OR3Lts48GShqOIVEbPjCZgSsL8lRBlw0YiALN2W7tGOX7N4GB3EWVFTh2 5lAYX/Rz2MXC+wAAAAAAAA== --------------ms010502010400020402070302-- From lha@apple.com Wed May 12 15:58:36 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8921C3A6801 for ; Wed, 12 May 2010 15:58:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.299 X-Spam-Level: X-Spam-Status: No, score=-106.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0vsTG1N4x3w0 for ; Wed, 12 May 2010 15:58:35 -0700 (PDT) Received: from mail-out4.apple.com (mail-out4.apple.com [17.254.13.23]) by core3.amsl.com (Postfix) with ESMTP id D0F623A67D6 for ; Wed, 12 May 2010 15:58:35 -0700 (PDT) Received: from relay11.apple.com (relay11.apple.com [17.128.113.48]) by mail-out4.apple.com (Postfix) with ESMTP id 1415C99724EA for ; Wed, 12 May 2010 15:58:25 -0700 (PDT) X-AuditID: 11807130-b7c56ae000001d33-2e-4beb32904ab9 Received: from gertie.apple.com (gertie.apple.com [17.151.62.15]) by relay11.apple.com (Apple SCV relay) with SMTP id 1F.BC.07475.0923BEB4; Wed, 12 May 2010 15:58:24 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from nutcracker.apple.com (nutcracker.apple.com [17.201.21.139]) by gertie.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <0L2B00FQ6X5BOA80@gertie.apple.com> for certid@ietf.org; Wed, 12 May 2010 15:58:24 -0700 (PDT) From: =?iso-8859-1?Q?Love_H=F6rnquist_=C5strand?= In-reply-to: <4BEB2DC7.5020409@stpeter.im> Date: Wed, 12 May 2010 15:58:23 -0700 Message-id: References: <4BEB0FBF.5070502@KingsMountain.com> <4BEB2DC7.5020409@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1147.1) X-Brightmail-Tracker: AAAAAQAAAZE= Cc: certid@ietf.org Subject: Re: [certid] Comments on draft-saintandre-tls-server-id-check-03 X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2010 22:58:36 -0000 12 maj 2010 kl. 15:37 skrev Peter Saint-Andre: >> So I'm not sure right now what to say about that. I suspect we can still >> stipulate that the only RDN having attr type of CN that we'll pay >> attention to is the one at the far end of the RDN sequence comprising >> the DN. > > We can stipulate that, but is it realistic? Yes, since that's what RFC 2818 said. Love From ark@eltex.net Wed May 12 16:02:59 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE7303A69BF for ; Wed, 12 May 2010 16:02:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.105 X-Spam-Level: * X-Spam-Status: No, score=1.105 tagged_above=-999 required=5 tests=[AWL=-1.600, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_17=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DorEVJyPiOdd for ; Wed, 12 May 2010 16:02:59 -0700 (PDT) Received: from lebedev-225.itcwin.com (unknown [88.201.200.225]) by core3.amsl.com (Postfix) with ESMTP id E22CA3A6767 for ; Wed, 12 May 2010 16:02:58 -0700 (PDT) Received: from lebedev-225.itcwin.com (ark@localhost.my.domain [127.0.0.1]) by lebedev-225.itcwin.com (8.14.3/8.14.3) with ESMTP id o4CN2c02009419; Thu, 13 May 2010 03:02:38 +0400 (MSD) Received: (from ark@localhost) by lebedev-225.itcwin.com (8.14.3/8.14.3/Submit) id o4CN2cGx029902; Thu, 13 May 2010 03:02:38 +0400 (MSD) X-Authentication-Warning: lebedev-225.itcwin.com: ark set sender to ark@eltex.net using -f Date: Thu, 13 May 2010 03:02:38 +0400 From: ArkanoiD To: Love H?rnquist ?strand Message-ID: <20100512230238.GA22246@eltex.net> References: <4BEB0FBF.5070502@KingsMountain.com> <4BEB2DC7.5020409@stpeter.im> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: certid@ietf.org Subject: Re: [certid] Comments on draft-saintandre-tls-server-id-check-03 X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2010 23:03:00 -0000 It does not really answer the question, we should analyse certificates seen "in the wild" ;-) On Wed, May 12, 2010 at 03:58:23PM -0700, Love H?rnquist ?strand wrote: > > 12 maj 2010 kl. 15:37 skrev Peter Saint-Andre: > > >> So I'm not sure right now what to say about that. I suspect we can still > >> stipulate that the only RDN having attr type of CN that we'll pay > >> attention to is the one at the far end of the RDN sequence comprising > >> the DN. > > > > We can stipulate that, but is it realistic? > > Yes, since that's what RFC 2818 said. From mrex@sap.com Wed May 12 16:22:20 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBCEF3A68F0 for ; Wed, 12 May 2010 16:22:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.749 X-Spam-Level: X-Spam-Status: No, score=-7.749 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_50=0.001, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uX8gAvKMMPSo for ; Wed, 12 May 2010 16:22:19 -0700 (PDT) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id E1E873A6853 for ; Wed, 12 May 2010 16:22:18 -0700 (PDT) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id o4CNM4SK008921 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 May 2010 01:22:05 +0200 (MEST) From: Martin Rex Message-Id: <201005122322.o4CNM4BH004747@fs4113.wdf.sap.corp> To: turners@ieca.com (Sean Turner) Date: Thu, 13 May 2010 01:22:04 +0200 (MEST) In-Reply-To: <4BEB1F54.2060905@ieca.com> from "Sean Turner" at May 12, 10 05:36:20 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: certid@ietf.org Subject: Re: [certid] Comments on draft-saintandre-tls-server-id-check-03 X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2010 23:22:21 -0000 Sean Turner wrote: > > > So I'm not sure right now what to say about that. I suspect we can still > > stipulate that the only RDN having attr type of CN that we'll pay > > attention to is the one at the far end of the RDN sequence comprising > > the DN. > > I think a lot of DNs got concocted because X.500 implementers assumed > the examples in X.501 were normative. That is c=, o=, (4) ou=, cn=. > But, you're might be right about no descending ordering can be > assumed. If you look at the subjectName in the datatracker > certificate it's: > > CN = *.ietf.org > OU = Terms of use at www.verisign.com/rpa (c)05 > OU = Internet Engineering Task Force > O = IETF Trust > L = Reston > ST = Virginia > C = US When I received a request for help ~2 years ago doing a more complex processing/mapping/evaluation of Subject(Alt)Names and IssuerNames from X.509 certificates during logon at the application level, we created an additional intermediate format between ASN.1 DER and string representation. It consists of a (pre-sorted by OID) linked list of entries where each of the list entries carries the attribute (or sAN) OID and an UTF8 representation of the attribute value. (plus side info, like the original position in the ASN.1 DER encoding, whether it was the first element of an RDName set, and some other stuff). Basically the divide-and-conquer approach. split one problem into two smaller problems that are easier to solve. So when looking for a CN in subject, the app requests the subject name from a given cert an searches the resulting list for all occurences of the 2.5.4.cn(3) OID aka {3, "\x55\x04\x03" } Similarly, when looking for a server endpoint sAN match, the app requests the subjectaltname from a given cert and searches the resulting list for all occurrences of the dNSName pseudo-OID {4, "\x55\x1D\x11\x02" } and iPAddress pseudo-OID {4, "\x55\x1D\x11\x07" } as described in rfc2818. Concerning the list of sANs in the -04 draft, I came across these two Microsoft "other" sANs while implementing this: "msUPN" {10, "\x2B\x06\x01\x04\x01\x82\x37\x14\x02\x03"} "msGUID" { 9, "\x2B\x06\x01\x04\x01\x82\x37\x19\x01" } "msUPN" = 1.3.6.1.4.1.311.20.2.3 "msGUID" = 1.3.6.1.4.1.311.25.1 Which is also mention at the bottom of this page http://technet.microsoft.com/en-us/library/cc736326%28WS.10,printer%29.aspx -Martin From Jeff.Hodges@KingsMountain.com Wed May 12 16:23:41 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 09E183A6928 for ; Wed, 12 May 2010 16:23:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.07 X-Spam-Level: X-Spam-Status: No, score=-0.07 tagged_above=-999 required=5 tests=[AWL=-1.005, BAYES_50=0.001, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_17=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ARDLZAru2x0 for ; Wed, 12 May 2010 16:23:39 -0700 (PDT) Received: from outbound-mail-313.bluehost.com (cpoproxy3-pub.bluehost.com [67.222.54.6]) by core3.amsl.com (Postfix) with SMTP id A39E63A68F0 for ; Wed, 12 May 2010 16:23:39 -0700 (PDT) Received: (qmail 16099 invoked by uid 0); 12 May 2010 23:23:29 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by cpoproxy3.bluehost.com with SMTP; 12 May 2010 23:23:29 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kingsmountain.com; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=lIjFkC1jKnHytQgnI3hhoWNsZv6asNIaUygYpTES4rNYe2holBLOnrJNT96EXn5ajmtQnjiQyy6oEIoCQQtNJrkLa0WwokcacwqC2RTjTBKTN+PP5pUlIF46P3tYRApP; Received: from outbound4.ebay.com ([216.113.168.128] helo=[10.244.49.154]) by box514.bluehost.com with esmtpsa (SSLv3:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1OCLGz-0003g4-HS for certid@ietf.org; Wed, 12 May 2010 17:23:29 -0600 Message-ID: <4BEB3870.10904@KingsMountain.com> Date: Wed, 12 May 2010 16:23:28 -0700 From: =JeffH User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: IETF cert-based identity Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 216.113.168.128 authed with jeff.hodges+kingsmountain.com} Subject: Re: [certid] Comments on draft-saintandre-tls-server-id-check-03 X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2010 23:23:41 -0000 > From: ArkanoiD > > It does not really answer the question, we should analyse certificates seen > "in the wild" ;-) > > On Wed, May 12, 2010 at 03:58:23PM -0700, Love H?rnquist ?strand wrote: >> >> 12 maj 2010 kl. 15:37 skrev Peter Saint-Andre: >> >> >> So I'm not sure right now what to say about that. I suspect we can still >> >> stipulate that the only RDN having attr type of CN that we'll pay >> >> attention to is the one at the far end of the RDN sequence comprising >> >> the DN. >> > >> > We can stipulate that, but is it realistic? >> >> Yes, since that's what RFC 2818 said. in essence I'm agreed with ArkanoiD. In particular here's what RFC 2818 sez (in section 3.1 Server Identity).. If a subjectAltName extension of type dNSName is present, that MUST be used as the identity. Otherwise, the (most specific) Common Name field in the Subject field of the certificate MUST be used. ... ..which is ambiguous because X.501 does not explicitly state which RDN in the DN sequence is the most specific (it's implied) and there allegedly exist non-trivial slices of current practice don't necessarily follow that stipulation anyway (for whatever reasons). Also, we should note that the current rev of "CA/Browser Forum: Guidelines For The Issuance And Management Of Extended Validation Certificates (version 1.2)" specifies using CN (commonName) containing the host domain name /or/ dNSName in subjectAlternativeName (see section 8.1.1(2) therein), rather than deprecating use of subject:commonName (in that doc's notation). that doc also doesn't specify where in the DN's RDN sequence an RDN of type commonName should/must be placed. (so we have some evangelizing to do with the CABForum folk...) =JeffH From mrex@sap.com Wed May 12 16:29:46 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7D4C3A6938 for ; Wed, 12 May 2010 16:29:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.838 X-Spam-Level: X-Spam-Status: No, score=-7.838 tagged_above=-999 required=5 tests=[AWL=-0.003, BAYES_40=-0.185, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tCNOUcdMnwYc for ; Wed, 12 May 2010 16:29:46 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id 98D9F3A6942 for ; Wed, 12 May 2010 16:29:31 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id o4CNTKmY005346 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 May 2010 01:29:20 +0200 (MEST) From: Martin Rex Message-Id: <201005122329.o4CNTJZT004984@fs4113.wdf.sap.corp> To: stpeter@stpeter.im (Peter Saint-Andre) Date: Thu, 13 May 2010 01:29:19 +0200 (MEST) In-Reply-To: <4BEB2DC7.5020409@stpeter.im> from "Peter Saint-Andre" at May 12, 10 04:37:59 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal07 X-SAP: out Cc: certid@ietf.org Subject: Re: [certid] Comments on draft-saintandre-tls-server-id-check-03 X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2010 23:29:46 -0000 Peter Saint-Andre wrote: > > > So I'm not sure right now what to say about that. I suspect we can still > > stipulate that the only RDN having attr type of CN that we'll pay > > attention to is the one at the far end of the RDN sequence comprising > > the DN. > > We can stipulate that, but is it realistic? An X.509 cert may contain several CN= components, although this is much less common that multiple OU= components. My own server endpoint identification code (including the original string-representation-based) has always been checking all CN= components of a DName and no matter where within the dinstinguished name they are, but I noticed that Firefox and IE seem to check only one of them. -Martin From lha@apple.com Wed May 12 17:39:43 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5335D3A69CE for ; Wed, 12 May 2010 17:39:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.299 X-Spam-Level: X-Spam-Status: No, score=-106.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CzXXyOa-DGfi for ; Wed, 12 May 2010 17:39:42 -0700 (PDT) Received: from mail-out3.apple.com (mail-out3.apple.com [17.254.13.22]) by core3.amsl.com (Postfix) with ESMTP id 237C63A69C6 for ; Wed, 12 May 2010 17:39:41 -0700 (PDT) Received: from relay13.apple.com (relay13.apple.com [17.128.113.29]) by mail-out3.apple.com (Postfix) with ESMTP id 1B532926BC97 for ; Wed, 12 May 2010 17:39:32 -0700 (PDT) X-AuditID: 1180711d-b7c17ae00000693e-b9-4beb4a430440 Received: from elliott.apple.com (elliott.apple.com [17.151.62.13]) by relay13.apple.com (Apple SCV relay) with SMTP id 2C.9B.26942.34A4BEB4; Wed, 12 May 2010 17:39:32 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from nutcracker.apple.com (nutcracker.apple.com [17.201.21.139]) by elliott.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <0L2C00G6O1TVA150@elliott.apple.com> for certid@ietf.org; Wed, 12 May 2010 17:39:31 -0700 (PDT) From: =?iso-8859-1?Q?Love_H=F6rnquist_=C5strand?= In-reply-to: <4BEB3870.10904@KingsMountain.com> Date: Wed, 12 May 2010 17:39:31 -0700 Message-id: References: <4BEB3870.10904@KingsMountain.com> To: =JeffH X-Mailer: Apple Mail (2.1147.1) X-Brightmail-Tracker: AAAAAQAAAZE= Cc: IETF cert-based identity Subject: Re: [certid] Comments on draft-saintandre-tls-server-id-check-03 X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 May 2010 00:39:43 -0000 12 maj 2010 kl. 16:23 skrev =JeffH: > ..which is ambiguous because X.501 does not explicitly state which RDN in the DN sequence is the most specific (it's implied) and there allegedly exist non-trivial slices of current practice don't necessarily follow that stipulation anyway (for whatever reasons). rfc5280 claims that dn are hierarchical, and it make sense when you apply name constraints on the subject DN (permitted/excluded subtree). Love From jorton@redhat.com Thu May 13 00:26:05 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 426203A6BA7 for ; Thu, 13 May 2010 00:26:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.699 X-Spam-Level: X-Spam-Status: No, score=-107.699 tagged_above=-999 required=5 tests=[BAYES_50=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y4-2pLvsV1tR for ; Thu, 13 May 2010 00:26:04 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by core3.amsl.com (Postfix) with ESMTP id C88433A6BB5 for ; Thu, 13 May 2010 00:20:33 -0700 (PDT) Received: from int-mx08.intmail.prod.int.phx2.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.21]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o4D7KH2N007012 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 13 May 2010 03:20:17 -0400 Received: from turnip.manyfish.co.uk (vpn-9-55.rdu.redhat.com [10.11.9.55]) by int-mx08.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id o4D7KEEk022635 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 May 2010 03:20:16 -0400 Received: from jorton by turnip.manyfish.co.uk with local (Exim 4.69) (envelope-from ) id 1OCSiL-0000mT-Vq; Thu, 13 May 2010 08:20:14 +0100 Date: Thu, 13 May 2010 08:20:13 +0100 From: Joe Orton To: Love =?utf-8?Q?H=C3=B6rnquist_=C3=85strand?= Message-ID: <20100513072013.GA2725@redhat.com> References: <4BEB0FBF.5070502@KingsMountain.com> <4BEB2DC7.5020409@stpeter.im> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.20 (2009-08-17) Organization: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in UK and Wales under Company Registration No. 03798903 Directors: Michael Cunningham (USA), Brendan Lane (Ireland), Matt Parson (USA), Charlie Peters (USA) X-Scanned-By: MIMEDefang 2.67 on 10.5.11.21 Cc: certid@ietf.org Subject: Re: [certid] Comments on draft-saintandre-tls-server-id-check-03 X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 May 2010 07:26:05 -0000 On Wed, May 12, 2010 at 03:58:23PM -0700, Love Hörnquist Åstrand wrote: > > 12 maj 2010 kl. 15:37 skrev Peter Saint-Andre: > > >> So I'm not sure right now what to say about that. I suspect we can still > >> stipulate that the only RDN having attr type of CN that we'll pay > >> attention to is the one at the far end of the RDN sequence comprising > >> the DN. > > > > We can stipulate that, but is it realistic? > > Yes, since that's what RFC 2818 said. RFC 2818 says that you use the most specific CN RDN. Not the most specific RDN, iff it is a CN. That is completely different. The stats I ran said that maybe 10/20% of existing certs place the CN somewhere other than the most specific field. Who out there is going to change their software to implement a CN matching algorithm which breaks interop with 10/20% of SSL servers? Regards, Joe From ietf-certid@velox.ch Thu May 13 00:40:27 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A408C3A6936 for ; Thu, 13 May 2010 00:40:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bIcRrYfi6VKH for ; Thu, 13 May 2010 00:40:26 -0700 (PDT) Received: from appendix.velox.ch (appendix.velox.ch [62.75.148.60]) by core3.amsl.com (Postfix) with ESMTP id BFFAE3A6AA2 for ; Thu, 13 May 2010 00:40:23 -0700 (PDT) Received: from cortex.velox.ch (84-75-163-235.dclient.hispeed.ch [84.75.163.235]) (authenticated bits=0) by appendix.velox.ch (8.14.4/8.14.4/2.0) with ESMTP id o4D7eBJj008017 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 13 May 2010 09:40:12 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=velox.ch; s=appendix-177f; t=1273736412; bh=WREX92+kOh3+JqvofROvTvWX5fghv0lkuXpQtbnNl5w=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=n/NpJE4IhLZTr88oM1wqfZtp8DVfubZWwRkXT7OCiLcTR9pkWBy73ss1bpGS5gGMl msMYvj6Kf+LePKGxCLlTbcPGW9GoB/S5eRAM/L9wlLv1mzyyV458KpDHCBHdAMfE3C a1eD2yqICHYGVjhgPaxXqGs/O26lS6BWAQq/JDs4cDzSfZ/xfOnpvaWQn57rB6WeL9 9DWlgPqp13DeozyENja7QGoY2aJE0FDfMeXrK5uISLSuMq8ZOc1Bx9hon1R59RLJ/b gClf22QA0M+wsLqLV/EJuby8oHbDps4miKmATh6JMgFVyX7nAbYDxSOcpynuJLhSYY Zb1gTnJa2KFfw== Message-ID: <4BEBACDC.60903@velox.ch> DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=velox.ch; s=cortex-8a58; t=1273736411; bh=WREX92+kOh3+JqvofROvTvWX5fghv0lkuXpQtbnNl5w=; h=Date:From:MIME-Version:To:Subject:References:In-Reply-To: Content-Type:Content-Transfer-Encoding; b=m/X/rHF9cw25QMVRt8J7eElixrpAFrq//Qk7u0PlgRjAujocXQZsY1PG8VK4CSZRh ZWUgCByozkULCz4E6tz5z1LX4Q2f+uXGwgU2Y5xywiBSNN9lvefiPZuVfMwtJwkixu YVADoBYfzOSdBvW85t1OFQAHMI5aNCF8nzpQDSouUzFLLqLODC7C9LRAMak33sc2p/ x2UeRLJNwfh4Hcr7jmNdZMLk6DoQ3dcGAVdQHWS1h+Pt2PvvlYzgSkspWtHaG2lbdB Ew9lf+2bzNa5jSttD7YMMLmEM+inJE3qYF5YbiqRIO+QNQSmwjckGOumCDufg7tgpP mr4gj4AldPxUA== Date: Thu, 13 May 2010 09:40:12 +0200 From: Kaspar Brand User-Agent: Thunderbird/3.0 MIME-Version: 1.0 To: certid@ietf.org References: <4BEB0FBF.5070502@KingsMountain.com> <4BEB2DC7.5020409@stpeter.im> <20100512230238.GA22246@eltex.net> In-Reply-To: <20100512230238.GA22246@eltex.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [certid] Comments on draft-saintandre-tls-server-id-check-03 X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 May 2010 07:40:27 -0000 On 13.05.2010 01:02, ArkanoiD wrote: > It does not really answer the question, we should analyse certificates seen > "in the wild" ;-) Here's some data. It's from a sample of about 90,000 non self-issued certs (from commercial CAs, most likely reflecting shares like those in http://news.netcraft.com/SSL-survey). The data are from the beginning of 2009, but I don't think the situation has considerably changed in between. The second colum shows the RDNs in the order they have in the ASN.1 subject SEQUENCE, while the first colum gives the number of occurences of such a cert (only the "top 15" are shown). 19464 C, O, OU, OU, OU, CN 15657 C, ST, L, O, OU, CN 6859 O, OU, CN 5603 C, ST, L, O, OU, OU, CN 4983 C, ST, L, O, OU, OU, OU, OU, CN 4813 C, ST, L, O, CN 4746 O, OU, OU, OU, CN 3915 C, postalCode, ST, L, streetAddress, O, OU, OU, OU, CN 3884 C, postalCode, ST, L, streetAddress, O, OU, OU, CN 2820 O, CN, OU 2726 C, ST, L, O, OU, CN, emailAddress 1565 C, OU, O, CN 1401 OU, OU, CN 1311 C, postalCode, ST, L, streetAddress, O, OU, CN 1212 C, ST, L, O, OU, OU, OU, CN [...] >> 12 maj 2010 kl. 15:37 skrev Peter Saint-Andre: >> >>>> So I'm not sure right now what to say about that. I suspect we can still >>>> stipulate that the only RDN having attr type of CN that we'll pay >>>> attention to is the one at the far end of the RDN sequence comprising >>>> the DN. >>> >>> We can stipulate that, but is it realistic? Note that "the one at the far end of the RDN sequence" should not imply that the CN should necessarily be the very last element of the subject. Looking at cases like 2820 O, CN, OU 2726 C, ST, L, O, OU, CN, emailAddress I would only stipulate that if multiple CNs occur in the subject (and they can be found in that sample, btw), only the last one is taken into account. Kaspar From ietf-certid@velox.ch Thu May 13 01:32:23 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E5353A6B91 for ; Thu, 13 May 2010 01:32:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kwcJix+b6z87 for ; Thu, 13 May 2010 01:32:22 -0700 (PDT) Received: from appendix.velox.ch (appendix.velox.ch [62.75.148.60]) by core3.amsl.com (Postfix) with ESMTP id D55B23A6B9A for ; Thu, 13 May 2010 01:29:03 -0700 (PDT) Received: from cortex.velox.ch (84-75-163-235.dclient.hispeed.ch [84.75.163.235]) (authenticated bits=0) by appendix.velox.ch (8.14.4/8.14.4/2.0) with ESMTP id o4D8SqAN025789 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 13 May 2010 10:28:52 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=velox.ch; s=appendix-177f; t=1273739332; bh=iUYnGpoqC9eRcOugQ0V1IKkU5c6nLhgnS+ueJVeHK1E=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=IMVnvvV7flkBmw4FUasDJn/stJviMfcmoxdlcOiujhS+aBis8i4CalfnTC735BGxD Pxys4wcUg05Q9d9k6HbkAey6/fLGD+sOFzyeFTnb+97jz9TS73kegjK6Z3dmKwG87p QaWcMAD7sSlQg0uuPhPEwz/fj2LpqdJtBd/2svulEVKeCSg1OSzozh492Ibd2Gl1oO /WxkbNNdMtm2q7eTB9XETG9O7X21Dc4Wt+Ulreucs352J6SiPRzbItj+jc+ZDuSaTn P1OYWkSveXsIvSq/Znn2wMvIN7O+g5fQ3w2XfoUXEyYa5EdIxXxv6aFo3p3hMSFq+H wgGrumRS4YkBQ== Message-ID: <4BEBB843.6020600@velox.ch> DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=velox.ch; s=cortex-8a58; t=1273739331; bh=iUYnGpoqC9eRcOugQ0V1IKkU5c6nLhgnS+ueJVeHK1E=; h=Date:From:MIME-Version:To:Subject:References:In-Reply-To: Content-Type:Content-Transfer-Encoding; b=hdzwE+bONprr3WqZTCSMLLt7fbeTUk3rl460mEJs6Go6SW2CJi5H6i6ZmzES+ikNH YWB0dm7mVXCXL0DLFuUUuMz8HdnwTRZsRY6icYUZmCaT83TrN9sgfcSaJTrF1+KHHW h0dv2fzXG99c89srN7Z9eA1iXkUanHf+tP3CbBK3CV4hOvD8kbEF5mF2vpU7UMhXz6 aWkRDi0Oq1oeCz8yUapEmkv8bOvWblHIiFeFN4+X8pHRTXphyn7Ygsq7+LxAI4X14/ orZPCBTxokP/825wx0k42YmWZFGeLdTV/jv70J5fTqNEQhx2pVqDDwRG/3IBcQ6yM2 ejdi0GD6O5AnQ== Date: Thu, 13 May 2010 10:28:51 +0200 From: Kaspar Brand User-Agent: Thunderbird/3.0 MIME-Version: 1.0 To: certid@ietf.org References: <4BDB1F71.2050207@stpeter.im> In-Reply-To: <4BDB1F71.2050207@stpeter.im> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [certid] version -04 of CertID draft X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 May 2010 08:32:23 -0000 A few more comments about draft -04: > 2.1. Subject Naming in PKIX Certificates > [...] > "string representation" of a DN before being rendered. Often such a > DN string representation is ordered from left-to-right, most specific > to most general. See [LDAP-AUTH] for details. I would suggest to replace this with a reference to RFC 4514 (not 4513). > 2.2. PKIX Certificate Name Rules > > The following rules apply to the representation of application server > identities in PKIX certificates issued by certification authorities. > > 1. The certification authority MUST issue the certificate based on > the DNS domain name (not an IP address) at which the server will > provide the relevant service. With the current draft, "relative" domain names (such as "www", "mail" etc.) are also permitted as DNS-IDs or CN-IDs, from what I understand. Is this a deliberate decision, or should domain names possibly be required to be fully qualified (or "absolute", in RFC-1034 speak)? If the latter, then it would probably make sense to add an entry for "DNS domain name" to section 1.3 and explicitly state that it's required to be absolute / fully qualified. > 3.3. Seeking a Match > > Once the client has constructed its order list of reference > identifiers and has received the server's presented identifiers in > the form of an PKIX certificate, the client checks its reference Nit: "a PKIX certificate" > Note: A client MUST NOT seek a match for a reference identifier of > CN-ID if the presented identifiers include an SRV-ID, URI-ID, > DNS-ID, or any application-specific subjectAltName extensions, and > MUST NOT check a Common Name in the certificate if it is other > than the last Relative Distinguished Name (RDN) in within the > sequence of RDNs making up the Distinguished Name within the > certificate's subjectName. As already mentioned elsewhere, this requirement is probably too strict. I suggest changing to something like "must only check against the last Common Name RDN in the sequence of RDNs making up the Distinguished Name within the certificate's subjectName". > 3.4.4. Checking of DNS Domain Names in Common Names > > As noted, a client MUST NOT seek a match for a reference identifier > of CN-ID if the presented identifiers include an SRV-ID, URI-ID, > DNS-ID, or any application-specific subjectAltName extensions. > > Therefore, if and only if the identity set does not include > subjectAltName extensions of type dNSName, SRVName, or > uniformResourceIdentifier (or any application-specific subjectAltName > extensions), the client MAY as a fallback check for a DNS domain name > in the value of the last Relative Distinguished Name (RDN), if it is > of type Common Name (CN), within the sequence of RDNs making up the > Distinguished Name within the certificate's subjectName. (Note: The > term "last" refers to the DER order, which is often not the string > order presented to a user; the order that is applied here MUST be the > DER order.) See above - should be adapted accordingly. > 4.3. Internationalized Doman Names -> "Domain" Kaspar From ark@eltex.net Thu May 13 04:38:11 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E92103A69D2 for ; Thu, 13 May 2010 04:38:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.605 X-Spam-Level: * X-Spam-Status: No, score=1.605 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 71Sf4QKl1rrP for ; Thu, 13 May 2010 04:38:11 -0700 (PDT) Received: from lebedev-225.itcwin.com (unknown [88.201.200.225]) by core3.amsl.com (Postfix) with ESMTP id 7DC533A6833 for ; Thu, 13 May 2010 04:34:17 -0700 (PDT) Received: from lebedev-225.itcwin.com (ark@localhost.my.domain [127.0.0.1]) by lebedev-225.itcwin.com (8.14.3/8.14.3) with ESMTP id o4DBY4Kj028333; Thu, 13 May 2010 15:34:04 +0400 (MSD) Received: (from ark@localhost) by lebedev-225.itcwin.com (8.14.3/8.14.3/Submit) id o4DBY48q007635; Thu, 13 May 2010 15:34:04 +0400 (MSD) X-Authentication-Warning: lebedev-225.itcwin.com: ark set sender to ark@eltex.net using -f Date: Thu, 13 May 2010 15:34:04 +0400 From: ArkanoiD To: Kaspar Brand Message-ID: <20100513113404.GA14086@eltex.net> References: <4BDB1F71.2050207@stpeter.im> <4BEBB843.6020600@velox.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <4BEBB843.6020600@velox.ch> User-Agent: Mutt/1.4.2.3i Cc: certid@ietf.org Subject: Re: [certid] version -04 of CertID draft X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 May 2010 11:38:12 -0000 On Thu, May 13, 2010 at 10:28:51AM +0200, Kaspar Brand wrote: > > As already mentioned elsewhere, this requirement is probably too strict. > I suggest changing to something like "must only check against the last > Common Name RDN in the sequence of RDNs making up the Distinguished Name > within the certificate's subjectName". I agree. From peter.sylvester@edelweb.fr Fri May 14 03:48:47 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B1B73A6A62 for ; Fri, 14 May 2010 03:48:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZB6ndIYNcH0U for ; Fri, 14 May 2010 03:48:45 -0700 (PDT) Received: from ganymede.on-x.com (ganymede.on-x.com [92.103.215.11]) by core3.amsl.com (Postfix) with ESMTP id 320BB3A6AE0 for ; Fri, 14 May 2010 03:48:37 -0700 (PDT) Received: from varuna.puteaux.on-x (varuna.puteaux.on-x [192.168.10.6]) by ganymede.on-x.com (Postfix) with ESMTP id F1200AB for ; Fri, 14 May 2010 10:41:20 +0200 (CEST) Received: from smtps.on-x.com (mintaka.puteaux.on-x [192.168.14.11]) by varuna.puteaux.on-x (Postfix) with ESMTP id 1094B17048 for ; Fri, 14 May 2010 10:48:47 +0200 (CEST) Received: from [192.168.0.20] (gut75-3-82-227-163-182.fbx.proxad.net [82.227.163.182]) by smtps.on-x.com (Postfix) with ESMTP id F3CE277D8 for ; Fri, 14 May 2010 10:48:46 +0200 (CEST) Message-ID: <4BED0E6E.1090303@edelweb.fr> Date: Fri, 14 May 2010 10:48:46 +0200 From: Peter Sylvester User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100423 Thunderbird/3.0.4 MIME-Version: 1.0 To: certid@ietf.org References: <4BEB3870.10904@KingsMountain.com> In-Reply-To: <4BEB3870.10904@KingsMountain.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [certid] Comments on draft-saintandre-tls-server-id-check-04 X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 May 2010 10:48:47 -0000 > > In particular here's what RFC 2818 sez (in section 3.1 Server Identity).. > > If a subjectAltName extension of type dNSName is present, that MUST > be used as the identity. Otherwise, the (most specific) Common Name > field in the Subject field of the certificate MUST be used. ... > > ..which is ambiguous because X.501 does not explicitly state which RDN > in the DN sequence is the most specific (it's implied) and there > allegedly exist non-trivial slices of current practice don't > necessarily follow that stipulation anyway (for whatever reasons). DNs as a sequences of RDNs form a hierarchical name space similar to the DNS name space. with the difference that the "labels" are not just a piece of texts but are structured , i.e. SET OF of attribute/values assertions. If one writes "a.b.c" then this is something that can be described as a string folling DNS name syntax, and I could use it in whatever environment. What is ambiguous in 2818 is that you may have a set of AVAs with more than one occurence of an AVA with common name. In theory... Using the term 'field' is somewhat sloppy wording. > > Also, we should note that the current rev of "CA/Browser Forum: > Guidelines For The Issuance And Management Of Extended Validation > Certificates (version 1.2)" > specifies using CN (commonName) containing the host domain name /or/ > dNSName in subjectAlternativeName (see section 8.1.1(2) therein), > rather than deprecating use of subject:commonName (in that doc's > notation). that doc also doesn't specify where in the DN's RDN > sequence an RDN of type commonName should/must be placed. Indeed. This is not surprising, if one looks at certification policies, they are also pretty unprecise in that area. But: what is deprecated in RFC 2818 is the fact not using a subjectAltName: If a subjectAltName extension of type dNSName is present, that MUST be used as the identity. Otherwise, the (most specific) Common Name field in the Subject field of the certificate MUST be used. Although the use of the Common Name is existing practice, it is deprecated and Certification Authorities are encouraged to use the dNSName instead. At least, if I understand the "otherwise" correctly and apply Boolean an IETF logic. As soon as one adds a subjectAltName, a verifier conformant to 2818 doesn't even look for a common name. As a "best practice", one may say that having exactly one common name AVA in a single value RDN with ensures that the cert is recognized as one belonging to the intended host. and to have an identical value in a subjectAltName One may add that putting it as the last element in the sequence covers the 0.000001% of very strange things, I'd rather say that it is not necessary for this RDN to be the last (i.e. explicitely tell verifiers so) > > (so we have some evangelizing to do with the CABForum folk...) Well, my hourly fee is ... negotiable :-) I (really don't) wonder how many of the CAs in that forum allow a certificate request with two common names... I think it is very important that the RFC use clear wording that is also easy to understand by non native English. 7. The certificate SHOULD NOT represent the server's DNS domain name in a Relative Distinguished Name (RDN) of type Common Name (CN) (see [LDAP-SCHEMA]) within the subjectName field, even though it is recognized that many deployed clients still check for this legacy identifier configuration within certificate subjectName. I do not see any reason for this unless one adds 'only' before the within. see above. However, if this legacy identifer configuration is employed, then the server's DNS domain name MUST be placed in the last (most specific) RDN within the RDN sequence making up the certificate's subjectName, as the order of RDNs is determined by the DER- encoded Name within the server's PKIX certificate. If one takes the text without saying that subjectAltName has precedece, I think the message is wrong. The subject field of a PKIX Certificate is defined as a X.501 type Name [PKIX] and known as a Distinguished Name (DN). See also [X.501] A DN is an ordered sequence of attribute type and attribute value pairs (termed "attribute value assertions (AVAs)"), where the attributes are to be those of the subject. Each AVA is also termed a "Relative Distinguished Name (RDN)". The RDNs are ordered in the DN sequence from most general to most specific. this is simply wrong. DistinguishedName ::= RDNSequence RDNSequence ::= SEQUENCE OF RelativeDistinguishedName RelativeDistinguishedName ::= SET SIZE (1..MAX) OF AttributeTypeAndValue AttributeTypeAndValue ::= SEQUENCE { type AttributeType, value AttributeValue } Often such a DN string representation is ordered from left-to-right, most specific to most general. See [LDAP-AUTH] for details. I'd rather say that unfortunately both orderings occur and it not always obvious to see which is used. I know about a institude's CA that has country (C=DE) as last element got that certified. :-) 8. The certificate MUST NOT represent the server's DNS domain name by means of a series of Domain Component (DC) attributes (because the order of Domain Components is not guaranteed, certain attacks are possible if DC attributes are included). I think that this is also not nice wording. What is ment IMO is that the server MUST NOT assume that whatever is put in DCs is recognized as a domain name. One should be careful about such words, sine it may be that some extremely strict verifier misinterprets it. Talking about 'certain attacks' doesn't seem a useful information. 2. After the server provides its presented identifiers in the form of an PKIX certificate, the client checks each of its reference identifiers against the presented identifiers for the purpose of finding a match. 'presents its' instead of 'provides its presented' and remove 'after'. It maybe present out of band The reference identifiers is matched with identifiers included/present/provided/electable in a PKIX certificate belonging to the server, i.e. by which the intended communication of data verification can be authenticated cryptograhically. I don't really like PKIX here, one may have an X509 cert that is not conformant to the PKIX profile. In addition to checking identifiers, a client MAY complete further checks to ensure that the server is authorized to provide the requested service. However, methods for doing so (e.g., consulting local policy information) are out of scope for this document. The chapter talks about Server identity verification. This paragraph doesn't belong to this imo. o The list SHOULD NOT include a CN-ID; however, the CN-ID (if included) MUST be constructed only from the source domain and never from a target domain. Note: A client MUST NOT construct a reference identifier corresponding to Relative Distinguished Names (RDNs) other than the Common Name and MUST NOT check for such RDNs in the presented identifiers. In particular, this means that a client MUST NOT check a series of Domain Component (DC) attributes if included in the certificate (because the order of Domain Components is not guaranteed, certain attacks are possible if DC attributes are checked). since a CN-ID is: CN-ID = a Relative Distinguished Name (RDN) of type Common Name (CN) what is the purpose of the note? 3.4.4 seems to have a lot of redundant information and not the same as already presented elsewhere. All text starting from thesecond paragraph can be replaced by Therefore, if and only if the identity set does not include subjectAltName extensions of type dNSName, SRVName, or uniformResourceIdentifier (or any application-specific subjectAltName extensions), the client MAY as a fallback check cfor a CN-ID. The examples may be put into the description of the certificate subject structure. 3.6: There may also be the case where the server does not present a cert at all. not the case of tls etc, but one may verify signatures of OCSP, TSAs etc. have fun /PS From stpeter@stpeter.im Fri May 28 15:01:08 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C0A9D3A687C for ; Fri, 28 May 2010 15:01:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.801 X-Spam-Level: * X-Spam-Status: No, score=1.801 tagged_above=-999 required=5 tests=[BAYES_50=0.001, J_CHICKENPOX_22=0.6, J_CHICKENPOX_23=0.6, J_CHICKENPOX_27=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4DjLSJhs1agr for ; Fri, 28 May 2010 15:01:06 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 1ECA13A6866 for ; Fri, 28 May 2010 15:01:06 -0700 (PDT) Received: from leavealone.cisco.com (72-163-0-129.cisco.com [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id B073E40E3E; Fri, 28 May 2010 16:00:54 -0600 (MDT) Message-ID: <4C003D15.4060408@stpeter.im> Date: Fri, 28 May 2010 16:00:53 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Peter Sylvester References: <4BEB3870.10904@KingsMountain.com> <4BED0E6E.1090303@edelweb.fr> In-Reply-To: <4BED0E6E.1090303@edelweb.fr> X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms080208000604080204050802" Cc: certid@ietf.org Subject: Re: [certid] Comments on draft-saintandre-tls-server-id-check-04 X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 May 2010 22:01:08 -0000 This is a cryptographically signed message in MIME format. --------------ms080208000604080204050802 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 5/14/10 2:48 AM, Peter Sylvester wrote: >=20 >=20 >> >> In particular here's what RFC 2818 sez (in section 3.1 Server Identity= ).. >> >> If a subjectAltName extension of type dNSName is present, that MUST= >> be used as the identity. Otherwise, the (most specific) Common Name= >> field in the Subject field of the certificate MUST be used. ... >> >> ..which is ambiguous because X.501 does not explicitly state which RDN= >> in the DN sequence is the most specific (it's implied) and there >> allegedly exist non-trivial slices of current practice don't >> necessarily follow that stipulation anyway (for whatever reasons). > DNs as a sequences of RDNs form a hierarchical name space similar to th= e > DNS name space. > with the difference that the "labels" are not just a piece of texts but= > are structured , i.e. > SET OF of attribute/values assertions. >=20 > If one writes "a.b.c" then this is something that can be described as a= > string folling DNS name syntax, > and I could use it in whatever environment. >=20 > What is ambiguous in 2818 is that you may have a set of AVAs with more= > than one > occurence of an AVA with common name. In theory... >=20 > Using the term 'field' is somewhat sloppy wording. We borrowed that wording from RFC 5280. Do you have a suggestion for improvement? And, from the perspective of this proposed BCP, does it make a material difference? >> Also, we should note that the current rev of "CA/Browser Forum: >> Guidelines For The Issuance And Management Of Extended Validation >> Certificates (version 1.2)" >> specifies using CN (commonName) containing the host domain name /or/ >> dNSName in subjectAlternativeName (see section 8.1.1(2) therein), >> rather than deprecating use of subject:commonName (in that doc's >> notation). that doc also doesn't specify where in the DN's RDN >> sequence an RDN of type commonName should/must be placed. >=20 > Indeed. This is not surprising, if one looks at certification policies,= > they are also pretty unprecise in that area. >=20 > But: what is deprecated in RFC 2818 is the fact not using > a subjectAltName: >=20 > If a subjectAltName extension of type dNSName is present, that MUST > be used as the identity. Otherwise, the (most specific) Common Name > field in the Subject field of the certificate MUST be used. Although= > the use of the Common Name is existing practice, it is deprecated an= d > Certification Authorities are encouraged to use the dNSName instead.= >=20 > At least, if I understand the "otherwise" correctly and apply > Boolean an IETF logic. >=20 > As soon as one adds a subjectAltName, a verifier conformant > to 2818 doesn't even look for a common name. >=20 > As a "best practice", one may say that having > exactly one common name AVA in a single value RDN with > ensures that the cert is recognized as one belonging > to the intended host. >=20 > and to have an identical value in a subjectAltName >=20 > One may add that putting it as the last element in the > sequence covers the 0.000001% of very strange things, > I'd rather say that it is not necessary for this RDN > to be the last (i.e. explicitely tell verifiers so) >=20 >> >> (so we have some evangelizing to do with the CABForum folk...) >=20 > Well, my hourly fee is ... negotiable :-) >=20 > I (really don't) wonder how many of the CAs in that forum allow a > certificate request with two common names... >=20 > I think it is very important that the RFC use clear wording that > is also easy to understand by non native English. >=20 > 7. The certificate SHOULD NOT represent the server's DNS domain nam= e > in a Relative Distinguished Name (RDN) of type Common Name (CN) > (see [LDAP-SCHEMA]) within the subjectName field, even though it= > is recognized that many deployed clients still check for this > legacy identifier configuration within certificate subjectName. >=20 > I do not see any reason for this unless one adds 'only' before the > within. see above. How about removing the words "within the subjectName field"? > However, if this legacy identifer configuration is employed, the= n > the server's DNS domain name MUST be placed in the last (most > specific) RDN within the RDN sequence making up the certificate'= s > subjectName, as the order of RDNs is determined by the DER- > encoded Name within the server's PKIX certificate. >=20 > If one takes the text without saying that subjectAltName has precedece,= > I think the message is wrong. Does this proposed BCP say that the subjectAltName has precedence? If that is not clear, then we need to clarify it. > The subject field of a PKIX Certificate is defined as a X.501 type > Name [PKIX] and known as a Distinguished Name (DN). See also [X.501= ] > A DN is an ordered sequence of attribute type and attribute value > pairs (termed "attribute value assertions (AVAs)"), where the > attributes are to be those of the subject. Each AVA is also termed = a > "Relative Distinguished Name (RDN)". The RDNs are ordered in the DN= > sequence from most general to most specific. >=20 > this is simply wrong. >=20 > DistinguishedName ::=3D RDNSequence >=20 > RDNSequence ::=3D SEQUENCE OF RelativeDistinguishedName >=20 > RelativeDistinguishedName ::=3D SET SIZE (1..MAX) OF > AttributeTypeAndValue >=20 > AttributeTypeAndValue ::=3D SEQUENCE { > type AttributeType, > value AttributeValue } Our working copy of version -05 currently says: The subject field of a PKIX certificate is defined as an X.501 type Name and known as a Distinguished Name (DN) -- see [X.501] and [PKIX]. A DN is an ordered sequence of Relative Distinguished Name (RDNs), where an RDN is a set (i.e., an unordered group) of type-and- value pairs [LDAP-DN], each of which asserts some attribute about the subject of the certificate. The RDNs are ordered in the DN sequence from most general to most specific. > Often such a > DN string representation is ordered from left-to-right, most specifi= c > to most general. See [LDAP-AUTH] for details. OK. In fact do we need to say anything about the order (specific to general or general to specific)? > I'd rather say that unfortunately both orderings occur and > it not always obvious to see which is used. I know about a > institude's CA that has country (C=3DDE) as last element > got that certified. :-) So: ... In practice, the RDNs can be ordered in the DN sequence from most general to most specific or most specific to general, and the order cannot be relied upon. Better? > 8. The certificate MUST NOT represent the server's DNS domain name > by means of a series of Domain Component (DC) attributes (becaus= e > the order of Domain Components is not guaranteed, certain attack= s > are possible if DC attributes are included). >=20 > I think that this is also not nice wording. What is ment IMO is > that the server MUST NOT assume that whatever is put in DCs > is recognized as a domain name. This section is about certificate issuance, not client processing (or server interpretation of the certificate, which so far is utterly out of scope for this proposed BCP). > One should be careful about such words, sine it may be that > some extremely strict verifier misinterprets it. Talking about > 'certain attacks' doesn't seem a useful information. Consider: 1. DC=3Dcom, DC=3Dexample, DC=3Dcn vs. 2. DC=3Dcn, DC=3Dexample, DC=3Dcom Clearly com.example.cn !=3D cn.example.com, but if one interpreted DCs then both of those DNS domain names would match #1 and #2. We can add more text about this to the spec. > 2. After the server provides its presented identifiers in the form > of an PKIX certificate, the client checks each of its reference > identifiers against the presented identifiers for the purpose of= > finding a match. >=20 > 'presents its' instead of 'provides its presented' > and remove 'after'. It maybe present out of band Sure. Changed. > The reference identifiers is matched with identifiers > included/present/provided/electable in a PKIX certificate > belonging to the server, i.e. by which the intended > communication of data verification can be authenticated > cryptograhically. >=20 > I don't really like PKIX here, one may have an X509 cert that is not > conformant to the PKIX profile. One may, but we're not trying to cover every possible profile of X.509v3 here, only those conformant to the PKIX profile. > In addition to checking identifiers, a client MAY complete further > checks to ensure that the server is authorized to provide the > requested service. However, methods for doing so (e.g., consulting > local policy information) are out of scope for this document. >=20 > The chapter talks about Server identity verification. This paragraph > doesn't belong to this imo. It's just an implementation note. I've added some clarifying text. > o The list SHOULD NOT include a CN-ID; however, the CN-ID (if > included) MUST be constructed only from the source domain and > never from a target domain. >=20 > Note: A client MUST NOT construct a reference identifier > corresponding to Relative Distinguished Names (RDNs) other than > the Common Name and MUST NOT check for such RDNs in the presented= > identifiers. In particular, this means that a client MUST NOT > check a series of Domain Component (DC) attributes if included in= > the certificate (because the order of Domain Components is not > guaranteed, certain attacks are possible if DC attributes are > checked). >=20 > since a CN-ID is: >=20 > CN-ID =3D a Relative Distinguished Name (RDN) of type Common Name > (CN) >=20 > what is the purpose of the note? The purpose of the note is to warn client developers against using DCs. > 3.4.4 seems to have a lot of redundant information and not the > same as already presented elsewhere.=20 Repetition is not necessarily a bad thing. We assume that client developers will read only section 3, not section 4. > All text starting from > thesecond paragraph can be replaced by >=20 > Therefore, if and only if the identity set does not include > subjectAltName extensions of type dNSName, SRVName, or > uniformResourceIdentifier (or any application-specific subjectAltNam= e > extensions), the client MAY as a fallback check cfor a CN-ID. Maybe, but I think the repetition is useful. I'll double-check this when I have more time. > The examples may be put into the description of the certificate subject= > structure. >=20 >=20 > 3.6: There may also be the case where the server does not present a cer= t > at all. not the case of tls etc, but one may verify signatures of OCSP,= > TSAs etc. Out of scope. We might write another spec about such use cases, but in this case we think we're covering at least 80% of the usage. > have fun Always. :) Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms080208000604080204050802 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWnDCC B1cwggY/oAMCAQICAVUwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQTAeFw0wOTA3MDYwMDAwMDFaFw0xMDA3MDYyMzU5NTlaMIHCMQswCQYDVQQG EwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEiMCAGA1UEChMZWE1Q UCBTdGFuZGFyZHMgRm91bmRhdGlvbjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0 aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcN AQkBFhJzdHBldGVyQHN0cGV0ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCas7Mrnh02GakN8sft+HJpU4MwBxEgrGDZ2ZzUxDDt2sEhM+9Q74h955MtgMhK3TeBf6Hs hDh/8Z9G//k2qNA0M2S5rejTqrmW0Jabca/L7BUZ0GhnU2N/2zeciFUmuZ4A2l1T5IMX2ZVP XnNIaefBtbImJAbDz3T0vxkzTtcqgW3wL83PMDiqiuM+e1k+VPvOW4f5ZSGkPIhYCDpWqNE5 wZvjrLNMc8jZOPs9DrsYuIVwU72Vhy1tkEh+w6YpYHrdEUAe+eKe6TuxqZ60e9z3O36uiV// Ms274iD6PbA/IGazJgaAdg6tvPehwTYGJAGmv3PsJKkLGjgoh+RrrM1LAgMBAAGjggOKMIID hjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFOyws3XWgIY9FP1POVqjdZP9Lu38MB0GA1UdEQQWMBSBEnN0cGV0ZXJA c3RwZXRlci5pbTCBqAYDVR0jBIGgMIGdgBR7iZySlyShhEcCy3T8LvSs3DLl86GBgaR/MH0x CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eYIBDzCCAUcGA1UdIASCAT4wggE6MIIBNgYLKwYBBAGBtTcBAgAw ggElMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQG CCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG8 BggrBgEFBQcCAjCBrzAUFg1TdGFydENvbSBMdGQuMAMCAQEagZZMaW1pdGVkIExpYWJpbGl0 eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENv bSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTMtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczMvY2xpZW50L2NhMEIGCCsGAQUFBzAC hjZodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MzLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUA A4IBAQBgv4xFXZqDKSOtnPOVbqOh1brj7oxRaVYk7N0MJG7x9Y/wkO3iwRwizVLcC1bA+D/R gyFilXx6IQWE63Ge2tu+Y4w5QoHYwuUFQuBZuxvZpOa3ykdgPlBQaBM8m+Ien0skwNggaizA X9Pc/sMLpP3jkO1iSF4agy4r5Ed+4G10mP5X0zO3gQwq9Uj4F9tX+58kU+fM1P8Sh+BYR4r/ kSbKE3tWcMaKblWPGwX0nYD26Je7Qb+uX/J5lCgozBrHXQWq8N98iklASf2pv+32Oi1dEjmM UgAm/J2+YmxaI02+c+H6QH8+F3RUjCiRg9XqUNjcrNrnTFnm/iMMZADktsXPMIIHVzCCBj+g AwIBAgIBVTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBMB4XDTA5MDcwNjAwMDAwMVoXDTEwMDcwNjIzNTk1OVowgcIxCzAJBgNVBAYTAlVTMREw DwYDVQQIEwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMSIwIAYDVQQKExlYTVBQIFN0YW5k YXJkcyBGb3VuZGF0aW9uMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0 cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJqzsyue HTYZqQ3yx+34cmlTgzAHESCsYNnZnNTEMO3awSEz71DviH3nky2AyErdN4F/oeyEOH/xn0b/ +Tao0DQzZLmt6NOquZbQlptxr8vsFRnQaGdTY3/bN5yIVSa5ngDaXVPkgxfZlU9ec0hp58G1 siYkBsPPdPS/GTNO1yqBbfAvzc8wOKqK4z57WT5U+85bh/llIaQ8iFgIOlao0TnBm+Oss0xz yNk4+z0Ouxi4hXBTvZWHLW2QSH7Dpilget0RQB754p7pO7GpnrR73Pc7fq6JX/8yzbviIPo9 sD8gZrMmBoB2Dq2896HBNgYkAaa/c+wkqQsaOCiH5GuszUsCAwEAAaOCA4owggOGMAkGA1Ud EwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNV HQ4EFgQU7LCzddaAhj0U/U85WqN1k/0u7fwwHQYDVR0RBBYwFIESc3RwZXRlckBzdHBldGVy LmltMIGoBgNVHSMEgaAwgZ2AFHuJnJKXJKGERwLLdPwu9KzcMuXzoYGBpH8wfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5ggEPMIIBRwYDVR0gBIIBPjCCATowggE2BgsrBgEEAYG1NwECADCCASUwLgYI KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUH AgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbwGCCsGAQUF BwICMIGvMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBlkxpbWl0ZWQgTGlhYmlsaXR5LCByZWFk IHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9j cnR1My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2Nz cC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNV HRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAGC/ jEVdmoMpI62c85Vuo6HVuuPujFFpViTs3QwkbvH1j/CQ7eLBHCLNUtwLVsD4P9GDIWKVfHoh BYTrcZ7a275jjDlCgdjC5QVC4Fm7G9mk5rfKR2A+UFBoEzyb4h6fSyTA2CBqLMBf09z+wwuk /eOQ7WJIXhqDLivkR37gbXSY/lfTM7eBDCr1SPgX21f7nyRT58zU/xKH4FhHiv+RJsoTe1Zw xopuVY8bBfSdgPbol7tBv65f8nmUKCjMGsddBarw33yKSUBJ/am/7fY6LV0SOYxSACb8nb5i bFojTb5z4fpAfz4XdFSMKJGD1epQ2Nys2udMWeb+IwxkAOS2xc8wggfiMIIFyqADAgECAgEP MA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQD EyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAzMzJaFw0x MjEwMjIyMTAzMzJaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC5o0luEj4gypQIp71Xi2TlXyLYrj9WkRy+d9BO 0FHPYnAsC99/jx/ibNRwIfAoFhZd+LDscdRSckvwuFSz0bKg3z+9o7cwlVAC9AwMWe8IM0Lx c+8etYxsX4WIamG9fjzzi5GAW5ESKzzIN3SxHSplyGCWFwx/pgf1f4y6O9/ym+4f6zaDYP6B x0r+SaJcr6eSGNm7X3EwX1v7XpRBY+aw019o7k72d0IX910F+XGt0OwNdM61Ff3FiTiexeUZ bWxCGm6GZl+SQVG9xYVIgHQaLXoQF+g2wzrmKCbVcZhqH+hrlRnD6PfCuEyX/BR6PlAPRDlQ 6f1u3wqik+LF5P15AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAd BgNVHQ4EFgQUe4mckpckoYRHAst0/C70rNwy5fMwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UX aYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UE AxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9Bggr BgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2Et Y3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYD VR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQg Q29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCBy ZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIB DQRDFkFTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVt YWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAUpcEDdsKFRCxFBxcSm+8oMTT fpS7fbZkxWHx5fHDjvAgaBQ+oY0tk4xtbD6VxeHYjxI63+hj8jICnqeVXPe34Bu+XzekIn2T lrnPCQobKdQF2p52QgUvIxSURed0jcBaCBV22DSKaUqDOzD/Tx6VQy78zpblXjRH7OALE/+H jzJVmspdnBUUtQOLYgPo924xkxR25VDdgtEE5vAXa/g2oCeZhy0ZEO4NbgIayAYCJcJRDz0h dD2Ahec65Kw6LB3N7VXEjiRR5/WoKwH/QteRzPJbFDc1somrApjm2cyg+5nbm1RHeFIz+GxX luRrPztvhNcby0PtAjqwY1txi4sW0R6ZJPuZ2DZ1/dzckoFhyZgFyOX3SEkNXVLldjTzneFJ FnVSzDbc720vq184jR7pYoI9+f5QJ96a0iLxEAG8SJ5auBwXI/w2FmKmwmdMvJ8/17+B4sMC IRrXrDQl2xzpVXh/Qcmk5nf+w8HFmqATGy1OUAQbXga7AySAUaYhvvFk50u0bO5DiUGwzrJO 3TrwvaC2Ei4EFaBmIVgG7TfU5TaaY9IcJSCQ7AGUYE3RFSRpsLOoA3DsxP42YERgS/Nxw29+ YqZtPoO2QPbNpI7xnHVCfNBabx3oDIf438nFfv8spw5BQqBSbEF1izJA57eE64CzHnt7lB20 OFD11avYopwxggPKMIIDxgIBATCBkjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBAgFVMAkGBSsOAwIaBQCgggIMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTEwMDUyODIyMDA1M1owIwYJKoZIhvcNAQkEMRYEFIGSjHEb3BDmg3VpOE+U Or4lKERKMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAijnKoW5geS2Cr662ssBzWaCaf5wju9Y0uOR9T6R6 m2/4ewmrHF4UR+v7UIx17vMkU7D3/G2IPAFVggZTAnhPaCgjkZp4UP2ynCVBr79gdyCOP3Fn ewtYDWH2EwsgGK8JzgdiCbIR8rsKYG8TF+H1AVrdJXzm4EsreLcfQo68MEDp97guraxDMUoa DdkZDGJrzpC8Hkb5bdtwoel7vFiFfll1vqrK1tNslfldwoHx3hLLAYuqEeg98EHjDqHPGCIV kb5hAvrxzHxVaBqf3Ttu+2IaC/it1018+qxzZUovEthwwsZIimApg9ttiakOumfOHBk1lZ/V duPvWLH7A4fKYQAAAAAAAA== --------------ms080208000604080204050802-- From peter.sylvester@edelweb.fr Sat May 29 08:12:31 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1DD13A6A08 for ; Sat, 29 May 2010 08:12:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.801 X-Spam-Level: * X-Spam-Status: No, score=1.801 tagged_above=-999 required=5 tests=[BAYES_50=0.001, J_CHICKENPOX_22=0.6, J_CHICKENPOX_23=0.6, J_CHICKENPOX_27=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EhRE1pIusG-r for ; Sat, 29 May 2010 08:12:27 -0700 (PDT) Received: from ganymede.on-x.com (ganymede.on-x.com [92.103.215.11]) by core3.amsl.com (Postfix) with ESMTP id CF8673A6870 for ; Sat, 29 May 2010 08:12:26 -0700 (PDT) Received: from varuna.puteaux.on-x (varuna.puteaux.on-x [192.168.10.6]) by ganymede.on-x.com (Postfix) with ESMTP id E3781150; Sat, 29 May 2010 13:37:54 +0200 (CEST) Received: from smtps.on-x.com (mintaka.puteaux.on-x [192.168.14.11]) by varuna.puteaux.on-x (Postfix) with ESMTP id 357D0170C1; Sat, 29 May 2010 13:47:33 +0200 (CEST) Received: from [192.168.0.17] (gut75-3-82-227-163-182.fbx.proxad.net [82.227.163.182]) by smtps.on-x.com (Postfix) with ESMTP id 0700C77D8; Sat, 29 May 2010 13:47:32 +0200 (CEST) Message-ID: <4C00FEC0.3080808@edelweb.fr> Date: Sat, 29 May 2010 13:47:12 +0200 From: Peter Sylvester User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100423 Thunderbird/3.0.4 MIME-Version: 1.0 To: Peter Saint-Andre References: <4BEB3870.10904@KingsMountain.com> <4BED0E6E.1090303@edelweb.fr> <4C003D15.4060408@stpeter.im> In-Reply-To: <4C003D15.4060408@stpeter.im> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: certid@ietf.org Subject: Re: [certid] Comments on draft-saintandre-tls-server-id-check-04 X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 May 2010 15:12:31 -0000 On 05/29/2010 12:00 AM, Peter Saint-Andre wrote: > On 5/14/10 2:48 AM, Peter Sylvester wrote: > >> >> >>> In particular here's what RFC 2818 sez (in section 3.1 Server Identity).. >>> >>> If a subjectAltName extension of type dNSName is present, that MUST >>> be used as the identity. Otherwise, the (most specific) Common Name >>> field in the Subject field of the certificate MUST be used. ... >>> >>> ..which is ambiguous because X.501 does not explicitly state which RDN >>> in the DN sequence is the most specific (it's implied) and there >>> allegedly exist non-trivial slices of current practice don't >>> necessarily follow that stipulation anyway (for whatever reasons). >>> >> DNs as a sequences of RDNs form a hierarchical name space similar to the >> DNS name space. >> with the difference that the "labels" are not just a piece of texts but >> are structured , i.e. >> SET OF of attribute/values assertions. >> >> If one writes "a.b.c" then this is something that can be described as a >> string folling DNS name syntax, >> and I could use it in whatever environment. >> >> What is ambiguous in 2818 is that you may have a set of AVAs with more >> than one >> occurence of an AVA with common name. In theory... >> The sentence starting with 'What" was the comment. >> Using the term 'field' is somewhat sloppy wording. >> > There are two usages of field. There is no 'Common namefield". > We borrowed that wording from RFC 5280. Do you have a suggestion for > improvement? And, from the perspective of this proposed BCP, does it > make a material difference? > There is a subsject field, but such thing as a 'Common name field'. Using vocabulary which is undefined is not the best way to explain best practices, i.e. to clarify usages, IMO. > >>> Also, we should note that the current rev of "CA/Browser Forum: >>> Guidelines For The Issuance And Management Of Extended Validation >>> Certificates (version 1.2)" >>> specifies using CN (commonName) containing the host domain name /or/ >>> dNSName in subjectAlternativeName (see section 8.1.1(2) therein), >>> rather than deprecating use of subject:commonName (in that doc's >>> notation). that doc also doesn't specify where in the DN's RDN >>> sequence an RDN of type commonName should/must be placed. >>> >> Indeed. This is not surprising, if one looks at certification policies, >> they are also pretty unprecise in that area. >> >> But: what is deprecated in RFC 2818 is the fact not using >> a subjectAltName: >> >> If a subjectAltName extension of type dNSName is present, that MUST >> be used as the identity. Otherwise, the (most specific) Common Name >> field in the Subject field of the certificate MUST be used. Although >> the use of the Common Name is existing practice, it is deprecated and >> Certification Authorities are encouraged to use the dNSName instead. >> >> At least, if I understand the "otherwise" correctly and apply >> Boolean an IETF logic. >> >> As soon as one adds a subjectAltName, a verifier conformant >> to 2818 doesn't even look for a common name. >> >> As a "best practice", one may say that having >> exactly one common name AVA in a single value RDN with >> ensures that the cert is recognized as one belonging >> to the intended host. >> >> and to have an identical value in a subjectAltName >> >> One may add that putting it as the last element in the >> sequence covers the 0.000001% of very strange things, >> I'd rather say that it is not necessary for this RDN >> to be the last (i.e. explicitely tell verifiers so) >> >> No comment here?? >>> (so we have some evangelizing to do with the CABForum folk...) >>> >> Well, my hourly fee is ... negotiable :-) >> >> I (really don't) wonder how many of the CAs in that forum allow a >> certificate request with two common names... >> >> I think it is very important that the RFC use clear wording that >> is also easy to understand by non native English. >> >> 7. The certificate SHOULD NOT represent the server's DNS domain name >> in a Relative Distinguished Name (RDN) of type Common Name (CN) >> (see [LDAP-SCHEMA]) within the subjectName field, even though it >> is recognized that many deployed clients still check for this >> legacy identifier configuration within certificate subjectName. >> >> I do not see any reason for this unless one adds 'only' before the >> within. see above. >> > How about removing the words "within the subjectName field"? > The point is not (since already said) that there is no such thing as 'an RDN of type Common Name', there are only AVAs but: The SHOULD NOT may be misleading for a non-native English. It may be understood as "It is not a good idea at all to put an attribute of type Common Name in any RDN since it can be misunderstood as the server's name independantly of what is put in the subjectAltname extension." 'represent' is ambiguous here. exampe, you a Common Name attribute containing the server's name and if the cert has a subjectAltName, have I 'represented' the server's name in the Common Name or not? I have put it in, I don't expect that someone verifies it there, but still, I have can think I have represented it in two places. > >> However, if this legacy identifer configuration is employed, then >> the server's DNS domain name MUST be placed in the last (most >> specific) RDN within the RDN sequence making up the certificate's >> subjectName, as the order of RDNs is determined by the DER- >> encoded Name within the server's PKIX certificate. >> >> If one takes the text without saying that subjectAltName has precedece, >> I think the message is wrong. >> > Does this proposed BCP say that the subjectAltName has precedence? If > that is not clear, then we need to clarify it. > As I said, here you have room for clarification. You essentially rewrite 2818 (the most specific) without clarifying the amiguity of multiple AVAs and without mentioning that is is a BAD idea to have several attributs with type Common Name. "However, if this legacy identifier configuration is employed, in order to be surely recognizable, there SHOULD only be one attribute of type Common Name, and that ava SHOULD occur in a single element RDN." > >> The subject field of a PKIX Certificate is defined as a X.501 type >> Name [PKIX] and known as a Distinguished Name (DN). See also [X.501] >> A DN is an ordered sequence of attribute type and attribute value >> pairs (termed "attribute value assertions (AVAs)"), where the >> attributes are to be those of the subject. Each AVA is also termed a >> "Relative Distinguished Name (RDN)". The RDNs are ordered in the DN >> sequence from most general to most specific. >> >> this is simply wrong. >> >> DistinguishedName ::= RDNSequence >> >> RDNSequence ::= SEQUENCE OF RelativeDistinguishedName >> >> RelativeDistinguishedName ::= SET SIZE (1..MAX) OF >> AttributeTypeAndValue >> >> AttributeTypeAndValue ::= SEQUENCE { >> type AttributeType, >> value AttributeValue } >> > Our working copy of version -05 currently says: > > The subject field of a PKIX certificate is defined as an X.501 type > Name and known as a Distinguished Name (DN) -- see [X.501] and > [PKIX]. A DN is an ordered sequence of Relative Distinguished Name > (RDNs), where an RDN is a set (i.e., an unordered group) of type-and- > value pairs [LDAP-DN], each of which asserts some attribute about the > subject of the certificate. The RDNs are ordered in the DN sequence > from most general to most specific. > Ok. > >> Often such a >> DN string representation is ordered from left-to-right, most specific >> to most general. See [LDAP-AUTH] for details. >> > OK. In fact do we need to say anything about the order (specific to > general or general to specific)? > The RDN order is the only thing clearly defined. What one should say is that unfortunately there are the two orders in textual representations multiplied by the two ways of reading them and that when tools are displaying rdns in windows, things may be worse. "When creating DNs, care must be taken in order to be sure that the desired order of the RDN sequence is obtained." > >> I'd rather say that unfortunately both orderings occur and >> it not always obvious to see which is used. I know about a >> institude's CA that has country (C=DE) as last element >> got that certified. :-) >> > So: > > ... In practice, the RDNs can be ordered in > the DN sequence from most general to most specific or most specific > to general, and the order cannot be relied upon. > > Better? > In the DN encoding, the first element is the most significant (for the decoding party). The encoding party MUST be careful that the first element is encoding receives the intended attribute. > >> 8. The certificate MUST NOT represent the server's DNS domain name >> by means of a series of Domain Component (DC) attributes (because >> the order of Domain Components is not guaranteed, certain attacks >> are possible if DC attributes are included). >> >> I think that this is also not nice wording. What is ment IMO is >> that the server MUST NOT assume that whatever is put in DCs >> is recognized as a domain name. >> > This section is about certificate issuance, not client processing (or > server interpretation of the certificate, which so far is utterly out of > scope for this proposed BCP). > "Certain attacks", IMO, that's not something to be used to justify a MUST NOT. The point is the word "represent". As above. > >> One should be careful about such words, sine it may be that >> some extremely strict verifier misinterprets it. Talking about >> 'certain attacks' doesn't seem a useful information. >> > Consider: > > 1. DC=com, DC=example, DC=cn > > vs. > > 2. DC=cn, DC=example, DC=com > > Clearly com.example.cn != cn.example.com, but if one interpreted DCs > then both of those DNS domain names would match #1 and #2. > And you can have dc=cn.example.com > We can add more text about this to the spec. > > >> 2. After the server provides its presented identifiers in the form >> of an PKIX certificate, the client checks each of its reference >> identifiers against the presented identifiers for the purpose of >> finding a match. >> >> 'presents its' instead of 'provides its presented' >> and remove 'after'. It maybe present out of band >> > Sure. Changed. > Ok > >> The reference identifiers is matched with identifiers >> included/present/provided/electable in a PKIX certificate >> belonging to the server, i.e. by which the intended >> communication of data verification can be authenticated >> cryptograhically. >> >> I don't really like PKIX here, one may have an X509 cert that is not >> conformant to the PKIX profile. >> > One may, but we're not trying to cover every possible profile of X.509v3 > here, only those conformant to the PKIX profile. > fair. > >> In addition to checking identifiers, a client MAY complete further >> checks to ensure that the server is authorized to provide the >> requested service. However, methods for doing so (e.g., consulting >> local policy information) are out of scope for this document. >> >> The chapter talks about Server identity verification. This paragraph >> doesn't belong to this imo. >> > It's just an implementation note. I've added some clarifying text. > will see. > >> o The list SHOULD NOT include a CN-ID; however, the CN-ID (if >> included) MUST be constructed only from the source domain and >> never from a target domain. >> >> Note: A client MUST NOT construct a reference identifier >> corresponding to Relative Distinguished Names (RDNs) other than >> the Common Name and MUST NOT check for such RDNs in the presented >> identifiers. In particular, this means that a client MUST NOT >> check a series of Domain Component (DC) attributes if included in >> the certificate (because the order of Domain Components is not >> guaranteed, certain attacks are possible if DC attributes are >> checked). >> >> since a CN-ID is: >> >> CN-ID = a Relative Distinguished Name (RDN) of type Common Name >> (CN) >> >> what is the purpose of the note? >> > The purpose of the note is to warn client developers against using DCs. > Hm, need to think more. > >> 3.4.4 seems to have a lot of redundant information and not the >> same as already presented elsewhere. >> > Repetition is not necessarily a bad thing. We assume that client > developers will read only section 3, not section 4. > You seem to consider this as a matter of style, I don't. We may be in violant disagreement, I don't fight. :-) > >> All text starting from >> thesecond paragraph can be replaced by >> >> Therefore, if and only if the identity set does not include >> subjectAltName extensions of type dNSName, SRVName, or >> uniformResourceIdentifier (or any application-specific subjectAltName >> extensions), the client MAY as a fallback check cfor a CN-ID. >> > Maybe, but I think the repetition is useful. I'll double-check this when > I have more time. > > Hm, if you succeed to get more time, tell me the recipe. :-) >> The examples may be put into the description of the certificate subject >> structure. >> >> >> 3.6: There may also be the case where the server does not present a cert >> at all. not the case of tls etc, but one may verify signatures of OCSP, >> TSAs etc. >> > Out of scope. We might write another spec about such use cases, but in > this case we think we're covering at least 80% of the usage. > Why out of scope? what has the interpretation of a cert to do with the way it is detected/communicated? regards Peter From peter.sylvester@edelweb.fr Sat May 29 10:47:46 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E4E1F3A6847 for ; Sat, 29 May 2010 10:47:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.901 X-Spam-Level: X-Spam-Status: No, score=0.901 tagged_above=-999 required=5 tests=[AWL=0.900, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kPs1SzvzgvwD for ; Sat, 29 May 2010 10:47:46 -0700 (PDT) Received: from ganymede.on-x.com (ganymede.on-x.com [92.103.215.11]) by core3.amsl.com (Postfix) with ESMTP id E42F73A6832 for ; Sat, 29 May 2010 10:47:45 -0700 (PDT) Received: from varuna.puteaux.on-x (varuna.puteaux.on-x [192.168.10.6]) by ganymede.on-x.com (Postfix) with ESMTP id AAA97150 for ; Sat, 29 May 2010 19:37:33 +0200 (CEST) Received: from smtps.on-x.com (mintaka.puteaux.on-x [192.168.14.11]) by varuna.puteaux.on-x (Postfix) with ESMTP id 787C3170C1 for ; Sat, 29 May 2010 19:47:14 +0200 (CEST) Received: from [192.168.0.17] (gut75-3-82-227-163-182.fbx.proxad.net [82.227.163.182]) by smtps.on-x.com (Postfix) with ESMTP id ED12977D8 for ; Sat, 29 May 2010 19:47:10 +0200 (CEST) Message-ID: <4C015310.5030708@edelweb.fr> Date: Sat, 29 May 2010 19:46:56 +0200 From: Peter Sylvester User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100423 Thunderbird/3.0.4 MIME-Version: 1.0 To: certid@ietf.org References: <4BEB3870.10904@KingsMountain.com> <4BED0E6E.1090303@edelweb.fr> <4C003D15.4060408@stpeter.im> <4C00FEC0.3080808@edelweb.fr> In-Reply-To: <4C00FEC0.3080808@edelweb.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [certid] Comments on draft-saintandre-tls-server-id-check-04 X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 May 2010 17:47:47 -0000 some more details. In 1.1: There is the possibility to indicate several identities: "Only a match between the client's reference identity and the server's presented identity enables the client to be sure that the certificate can legitimately be used to secure the connection." ==> "In general, a match between the client's reference identity and one of the server's presented identities is required to enable the client to be sure that the certificate can legitimately be used to authenticate the connection." (see: "The application server is identified by a name or names carried in the subject field and/or the subjectAltName extension of the certificate.") "The Internet Public Key Infrastructure" sounds ambiguous quite right to me. - The only thing of a PKI in question that is ever transmitted and visible in the Internet might be the server's certificate. - There is no "Internet PKI" (like the DNS). "in the context of the Internet Public Key Infrastructure using X.509" ==> "in the context of a Public Key Infrastructure using X.509". Likewise, during TLS negotiation the server presents its conception of the server's identity Application protocols have traditionally specified their own rules for representing and verifying server identities. I suggest to replace "represent" by "present". (The word represent seems to be used interchangeable with present in the current text). I'd prefer even 'indicate' instead. /PS From mrex@sap.com Mon May 31 08:19:17 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E13E3A6781 for ; Mon, 31 May 2010 08:19:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.712 X-Spam-Level: X-Spam-Status: No, score=-6.712 tagged_above=-999 required=5 tests=[AWL=-0.862, BAYES_50=0.001, HELO_EQ_DE=0.35, J_CHICKENPOX_22=0.6, J_CHICKENPOX_23=0.6, J_CHICKENPOX_27=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ISQB11+yl92E for ; Mon, 31 May 2010 08:19:15 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by core3.amsl.com (Postfix) with ESMTP id 154253A6828 for ; Mon, 31 May 2010 08:19:14 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id o4VFIID0027796 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 31 May 2010 17:18:18 +0200 (MEST) From: Martin Rex Message-Id: <201005311518.o4VFIHAw022209@fs4113.wdf.sap.corp> To: peter.sylvester@edelweb.fr (Peter Sylvester) Date: Mon, 31 May 2010 17:18:17 +0200 (MEST) In-Reply-To: <4C00FEC0.3080808@edelweb.fr> from "Peter Sylvester" at May 29, 10 01:47:12 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal08 X-SAP: out Cc: certid@ietf.org Subject: Re: [certid] Comments on draft-saintandre-tls-server-id-check-04 X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 May 2010 15:19:17 -0000 Peter Sylvester wrote: > > >> I (really don't) wonder how many of the CAs in that forum allow a > >> certificate request with two common names... > >> > >> I think it is very important that the RFC use clear wording that > >> is also easy to understand by non native English. > >> > >> 7. The certificate SHOULD NOT represent the server's DNS domain name > >> in a Relative Distinguished Name (RDN) of type Common Name (CN) > >> (see [LDAP-SCHEMA]) within the subjectName field, even though it > >> is recognized that many deployed clients still check for this > >> legacy identifier configuration within certificate subjectName. > >> > >> I do not see any reason for this unless one adds 'only' before the > >> within. see above. > >> > > How about removing the words "within the subjectName field"? > > > The point is not (since already said) that there is no such thing > as 'an RDN of type Common Name', there are only AVAs but: > > The SHOULD NOT may be misleading for a non-native English. > It may be understood as "It is not a good idea at all to put > an attribute of type Common Name in any RDN since it can be > misunderstood as the server's name independantly of what > is put in the subjectAltname extension." 'represent' is ambiguous > here. > > example, you a Common Name attribute containing the server's name > and if the cert has a subjectAltName, have I 'represented' the > server's name in the Common Name or not? I have put it in, > I don't expect that someone verifies it there, but still, I have > can think I have represented it in two places. There is going to be software that will check the CN= RDName of the certificate subject name for a match, even when subjectAltName of type dNSName are present. Either because they're fully backwards compatible or because they do not check subjectAltNames at all. While there have been few implementations checking for multiple CN= parts, the guideline in rfc-2818 for subjectAltNames seems to be much clearer, that there can be more than one, and more than one needs to be checked. The original approach to use a single certificate for several hosts was to use a wildcard (*). Personally, I prefer the multiple individual hostnames to the wildcard. Example: https://www.entrust.com It contains a CN=www.entrust.com and two subjectAltNames type dNSName with the values "www.entrust.com" and "secure.entrust.com" And a reasonable, fully backwards compatible approach to server endpoint identification would be to check all names for a match sequentially, and succeed when any one matches. -Martin > > > > > >> However, if this legacy identifer configuration is employed, then > >> the server's DNS domain name MUST be placed in the last (most > >> specific) RDN within the RDN sequence making up the certificate's > >> subjectName, as the order of RDNs is determined by the DER- > >> encoded Name within the server's PKIX certificate. > >> > >> If one takes the text without saying that subjectAltName has precedece, > >> I think the message is wrong. > >> > > Does this proposed BCP say that the subjectAltName has precedence? If > > that is not clear, then we need to clarify it. > > > As I said, here you have room for clarification. You essentially > rewrite 2818 (the most specific) without clarifying the > amiguity of multiple AVAs and without mentioning that > is is a BAD idea to have several attributs with type Common > Name. > > "However, if this legacy identifier configuration is employed, > in order to be surely recognizable, there SHOULD only > be one attribute of type Common Name, and that ava > SHOULD occur in a single element RDN." > > > > >> The subject field of a PKIX Certificate is defined as a X.501 type > >> Name [PKIX] and known as a Distinguished Name (DN). See also [X.501] > >> A DN is an ordered sequence of attribute type and attribute value > >> pairs (termed "attribute value assertions (AVAs)"), where the > >> attributes are to be those of the subject. Each AVA is also termed a > >> "Relative Distinguished Name (RDN)". The RDNs are ordered in the DN > >> sequence from most general to most specific. > >> > >> this is simply wrong. > >> > >> DistinguishedName ::= RDNSequence > >> > >> RDNSequence ::= SEQUENCE OF RelativeDistinguishedName > >> > >> RelativeDistinguishedName ::= SET SIZE (1..MAX) OF > >> AttributeTypeAndValue > >> > >> AttributeTypeAndValue ::= SEQUENCE { > >> type AttributeType, > >> value AttributeValue } > >> > > Our working copy of version -05 currently says: > > > > The subject field of a PKIX certificate is defined as an X.501 type > > Name and known as a Distinguished Name (DN) -- see [X.501] and > > [PKIX]. A DN is an ordered sequence of Relative Distinguished Name > > (RDNs), where an RDN is a set (i.e., an unordered group) of type-and- > > value pairs [LDAP-DN], each of which asserts some attribute about the > > subject of the certificate. The RDNs are ordered in the DN sequence > > from most general to most specific. > > > Ok. > > > >> Often such a > >> DN string representation is ordered from left-to-right, most specific > >> to most general. See [LDAP-AUTH] for details. > >> > > OK. In fact do we need to say anything about the order (specific to > > general or general to specific)? > > > The RDN order is the only thing clearly defined. What one should say > is that unfortunately there are the two orders in textual representations > multiplied by the two ways of reading them and that when tools > are displaying rdns in windows, things may be worse. > > "When creating DNs, care must be taken in order to be sure that > the desired order of the RDN sequence is obtained." > > > > >> I'd rather say that unfortunately both orderings occur and > >> it not always obvious to see which is used. I know about a > >> institude's CA that has country (C=DE) as last element > >> got that certified. :-) > >> > > So: > > > > ... In practice, the RDNs can be ordered in > > the DN sequence from most general to most specific or most specific > > to general, and the order cannot be relied upon. > > > > Better? > > > In the DN encoding, the first element is the most significant > (for the decoding party). > > The encoding party MUST be careful that the first element > is encoding receives the intended attribute. > > > >> 8. The certificate MUST NOT represent the server's DNS domain name > >> by means of a series of Domain Component (DC) attributes (because > >> the order of Domain Components is not guaranteed, certain attacks > >> are possible if DC attributes are included). > >> > >> I think that this is also not nice wording. What is ment IMO is > >> that the server MUST NOT assume that whatever is put in DCs > >> is recognized as a domain name. > >> > > This section is about certificate issuance, not client processing (or > > server interpretation of the certificate, which so far is utterly out of > > scope for this proposed BCP). > > > "Certain attacks", IMO, that's not something to be used to justify > a MUST NOT. > > The point is the word "represent". As above. > > > >> One should be careful about such words, sine it may be that > >> some extremely strict verifier misinterprets it. Talking about > >> 'certain attacks' doesn't seem a useful information. > >> > > Consider: > > > > 1. DC=com, DC=example, DC=cn > > > > vs. > > > > 2. DC=cn, DC=example, DC=com > > > > Clearly com.example.cn != cn.example.com, but if one interpreted DCs > > then both of those DNS domain names would match #1 and #2. > > > And you can have dc=cn.example.com > > We can add more text about this to the spec. > > > > > >> 2. After the server provides its presented identifiers in the form > >> of an PKIX certificate, the client checks each of its reference > >> identifiers against the presented identifiers for the purpose of > >> finding a match. > >> > >> 'presents its' instead of 'provides its presented' > >> and remove 'after'. It maybe present out of band > >> > > Sure. Changed. > > > Ok > > > >> The reference identifiers is matched with identifiers > >> included/present/provided/electable in a PKIX certificate > >> belonging to the server, i.e. by which the intended > >> communication of data verification can be authenticated > >> cryptograhically. > >> > >> I don't really like PKIX here, one may have an X509 cert that is not > >> conformant to the PKIX profile. > >> > > One may, but we're not trying to cover every possible profile of X.509v3 > > here, only those conformant to the PKIX profile. > > > fair. > > > > >> In addition to checking identifiers, a client MAY complete further > >> checks to ensure that the server is authorized to provide the > >> requested service. However, methods for doing so (e.g., consulting > >> local policy information) are out of scope for this document. > >> > >> The chapter talks about Server identity verification. This paragraph > >> doesn't belong to this imo. > >> > > It's just an implementation note. I've added some clarifying text. > > > will see. > > > >> o The list SHOULD NOT include a CN-ID; however, the CN-ID (if > >> included) MUST be constructed only from the source domain and > >> never from a target domain. > >> > >> Note: A client MUST NOT construct a reference identifier > >> corresponding to Relative Distinguished Names (RDNs) other than > >> the Common Name and MUST NOT check for such RDNs in the presented > >> identifiers. In particular, this means that a client MUST NOT > >> check a series of Domain Component (DC) attributes if included in > >> the certificate (because the order of Domain Components is not > >> guaranteed, certain attacks are possible if DC attributes are > >> checked). > >> > >> since a CN-ID is: > >> > >> CN-ID = a Relative Distinguished Name (RDN) of type Common Name > >> (CN) > >> > >> what is the purpose of the note? > >> > > The purpose of the note is to warn client developers against using DCs. > > > Hm, need to think more. > > > >> 3.4.4 seems to have a lot of redundant information and not the > >> same as already presented elsewhere. > >> > > Repetition is not necessarily a bad thing. We assume that client > > developers will read only section 3, not section 4. > > > You seem to consider this as a matter of style, I don't. > We may be in violant disagreement, I don't fight. :-) > > > >> All text starting from > >> thesecond paragraph can be replaced by > >> > >> Therefore, if and only if the identity set does not include > >> subjectAltName extensions of type dNSName, SRVName, or > >> uniformResourceIdentifier (or any application-specific subjectAltName > >> extensions), the client MAY as a fallback check cfor a CN-ID. > >> > > Maybe, but I think the repetition is useful. I'll double-check this when > > I have more time. > > > > > Hm, if you succeed to get more time, tell me the recipe. :-) > >> The examples may be put into the description of the certificate subject > >> structure. > >> > >> > >> 3.6: There may also be the case where the server does not present a cert > >> at all. not the case of tls etc, but one may verify signatures of OCSP, > >> TSAs etc. > >> > > Out of scope. We might write another spec about such use cases, but in > > this case we think we're covering at least 80% of the usage. > > > Why out of scope? what has the interpretation of a cert to do with > the way it is detected/communicated? > > > regards > Peter > > > _______________________________________________ > certid mailing list > certid@ietf.org > https://www.ietf.org/mailman/listinfo/certid > From ark@eltex.net Mon May 31 11:58:57 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC6533A6A37 for ; Mon, 31 May 2010 11:58:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.105 X-Spam-Level: ** X-Spam-Status: No, score=2.105 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vf79+1+ERsj0 for ; Mon, 31 May 2010 11:58:56 -0700 (PDT) Received: from lebedev-225.itcwin.com (unknown [88.201.200.225]) by core3.amsl.com (Postfix) with ESMTP id 7222A3A68D8 for ; Mon, 31 May 2010 11:58:55 -0700 (PDT) Received: from lebedev-225.itcwin.com (ark@localhost.my.domain [127.0.0.1]) by lebedev-225.itcwin.com (8.14.3/8.14.3) with ESMTP id o4VIwFdS029221; Mon, 31 May 2010 22:58:15 +0400 (MSD) Received: (from ark@localhost) by lebedev-225.itcwin.com (8.14.3/8.14.3/Submit) id o4VIwE74024369; Mon, 31 May 2010 22:58:14 +0400 (MSD) X-Authentication-Warning: lebedev-225.itcwin.com: ark set sender to ark@eltex.net using -f Date: Mon, 31 May 2010 22:58:14 +0400 From: ArkanoiD To: Martin Rex Message-ID: <20100531185813.GA32106@eltex.net> References: <4C00FEC0.3080808@edelweb.fr> <201005311518.o4VFIHAw022209@fs4113.wdf.sap.corp> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <201005311518.o4VFIHAw022209@fs4113.wdf.sap.corp> User-Agent: Mutt/1.4.2.3i Cc: certid@ietf.org Subject: Re: [certid] Comments on draft-saintandre-tls-server-id-check-04 X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 May 2010 18:58:57 -0000 On Mon, May 31, 2010 at 05:18:17PM +0200, Martin Rex wrote: > > > > example, you a Common Name attribute containing the server's name > > and if the cert has a subjectAltName, have I 'represented' the > > server's name in the Common Name or not? I have put it in, > > I don't expect that someone verifies it there, but still, I have > > can think I have represented it in two places. > > There is going to be software that will check the CN= RDName of the > certificate subject name for a match, even when subjectAltName of > type dNSName are present. Either because they're fully backwards > compatible or because they do not check subjectAltNames at all. Actually it should not, though i do not see any harm in behaving that way. > While there have been few implementations checking for multiple > CN= parts, the guideline in rfc-2818 for subjectAltNames seems > to be much clearer, that there can be more than one, and more > than one needs to be checked. ..and multiple CNs are likely to be an error. I'd better reject this certificate as invalid. > > Example: https://www.entrust.com > > It contains a CN=www.entrust.com and two subjectAltNames > type dNSName with the values "www.entrust.com" and "secure.entrust.com" > > And a reasonable, fully backwards compatible approach to server endpoint > identification would be to check all names for a match sequentially, > and succeed when any one matches. But we may safely ignore CN in this case, and that's what we probably intend to do.