From stpeter@stpeter.im Thu Jul 1 08:40:53 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 418203A69A0 for ; Thu, 1 Jul 2010 08:40:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.444 X-Spam-Level: X-Spam-Status: No, score=-2.444 tagged_above=-999 required=5 tests=[AWL=0.155, 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 aoZQMmPZcDaZ for ; Thu, 1 Jul 2010 08:40:48 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id BBE313A685C for ; Thu, 1 Jul 2010 08:40:15 -0700 (PDT) Received: from dhcp-64-101-72-121.cisco.com (dhcp-64-101-72-121.cisco.com [64.101.72.121]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id B08BB40E4D for ; Thu, 1 Jul 2010 09:40:26 -0600 (MDT) Message-ID: <4C2CB6E9.7080300@stpeter.im> Date: Thu, 01 Jul 2010 09:40:25 -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: <4C2C0CF6.10608@stpeter.im> In-Reply-To: <4C2C0CF6.10608@stpeter.im> 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="------------ms000107040303020303060600" Subject: Re: [certid] version -07 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, 01 Jul 2010 15:40:53 -0000 This is a cryptographically signed message in MIME format. --------------ms000107040303020303060600 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Diffs are here: http://tools.ietf.org/rfcdiff?url2=3Ddraft-saintandre-tls-server-id-check= -07.txt On 6/30/10 9:35 PM, Peter Saint-Andre wrote: > Based on all the list feedback provided so far, I've pushed out a new > version (-07) for your review: >=20 > http://www.ietf.org/id/draft-saintandre-tls-server-id-check-07.txt >=20 > I'll post diffs as soon as they are available. >=20 > Please note that I have not coordinated all of the modifications with m= y > co-editor, so Jeff might poke me tomorrow to complain. :) >=20 > Both draft-daboo-srv-email and draft-ietf-xmpp-3920bis depend on this > I-D, so we're hoping to gather any further feedback soon and finish it > off in the near future. >=20 > Peter --------------ms000107040303020303060600 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 hvcNAQkFMQ8XDTEwMDcwMTE1NDAyNVowIwYJKoZIhvcNAQkEMRYEFOFz5NuioDUIijv7JbNR mde7fzo5MF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAQk/neeyd6pI1ii13w97x7BhACrsonSrNCNjViB2G EAyugIfXddeupj5pOtjDKKlOQtt7aLQ1ECiaFtPD7f3n0N/FCDz760aZq8moKGsE7EBl3NqF jD6D8xBw+1lYrhS34cJKr/MWNRF0SGll66tcFRKw45srqN1/cZKZcNXHqYuO0/k2XJg7zLuc PEBrSl+3XiXa5KObxDzTxurs5JcoyUF4POflaIhXzBmwoix+aLAxPG6ElfHVvlZPOF7TrObu K8HbHwW3/MQwuxEtUo8fvdblOkn+e7o9sR+t1vqm2bAUcc3+kTibM8DTWwUNpAGIfsU1qBkY /yYijq7wROShewAAAAAAAA== --------------ms000107040303020303060600-- From turners@ieca.com Thu Jul 1 12:55:53 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 0874D3A6403 for ; Thu, 1 Jul 2010 12:55:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.923 X-Spam-Level: X-Spam-Status: No, score=-1.923 tagged_above=-999 required=5 tests=[AWL=0.675, BAYES_00=-2.599, 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 BV070Ph4mZDG for ; Thu, 1 Jul 2010 12:55:52 -0700 (PDT) Received: from smtp111.biz.mail.mud.yahoo.com (smtp111.biz.mail.mud.yahoo.com [209.191.68.76]) by core3.amsl.com (Postfix) with SMTP id F18083A6359 for ; Thu, 1 Jul 2010 12:55:51 -0700 (PDT) Received: (qmail 31103 invoked from network); 1 Jul 2010 19:56:00 -0000 Received: from thunderfish.local (turners@71.191.5.145 with plain) by smtp111.biz.mail.mud.yahoo.com with SMTP; 01 Jul 2010 12:56:00 -0700 PDT X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: hQ8VuwMVM1lsNspbLtxVFjfQzJqmTH4Yt3amFj8Yx8cLGQ5 tcJRCHFtvGUohMAd_RkOnHARKcUw8.q0fcH9AjVX2vzhL2vpBAEjvxvAzv3Q 7s7XbGLcCgnB9OLmGBMyvGdZGQghQkgr24tPlG9bUb7VJ6YtZxCV5BhAmSu0 lpVs_d1q1tX1Ejhn1VhtLsCDF5sXiQhcA6BdEbPlGy3O7hOGGXK7VG8_H8rd 1WTgDWro48LT_sGBDo.EO8h0elBQ5c3kHTCi0ToWpbW5zqvyi7tCZNMRK0YO knImiocPJFks3CQgYFx6WBfAdRMUZLgyTlHZVRwqDESfHvlWVS8krqQ-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4C2CF2CF.6090108@ieca.com> Date: Thu, 01 Jul 2010 15:55:59 -0400 From: Sean Turner User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: certid@ietf.org Content-Type: multipart/mixed; boundary="------------010407070603030902050408" Subject: [certid] [Fwd: I-D ACTION:draft-turner-ssl-must-not-01.txt] 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, 01 Jul 2010 19:55:53 -0000 This is a multi-part message in MIME format. --------------010407070603030902050408 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit This might be of interest to some. spt --------------010407070603030902050408 Content-Type: message/rfc822; name="I-D ACTION:draft-turner-ssl-must-not-01.txt.eml" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="I-D ACTION:draft-turner-ssl-must-not-01.txt.eml" X-Account-Key: account2 X-Mozilla-Keys: X-Apparently-To: turners@ieca.com via 216.252.120.72; Fri, 25 Jun 2010 10:50:36 -0700 Received-SPF: pass (mta1005.biz.mail.mud.yahoo.com: domain of i-d-announce-bounces@ietf.org designates 64.170.98.32 as permitted sender) X-YMailISG: hUwthQYcZArk4SD8fkFKhSPsUQ5FzAAF2FpF7MMKRnn04C6o Tealulbt8lps8pXfFNI65QJQW3WrkltTRgTcX9c.uP34i54fWSaoZCJUVzgi 8ggOAmdEV7oBwpJfr9Aur33z2QOJDAN4GHVb6pFpihsNQEM5rruHBH6AZjHe .QJ_erCNrA9iGYjsFInpDEF__J8It9ZHWaKqJzf47urYq6tJ6VIbAQFTAJRT P6Pq.Yeu7G5zwjjpN_SArsF6qtq1VQ_9Rz60cysv9MTAjptpO5LRL69bHKQD Sp6ncWFRzaWikaO_Ej5qjAbmG4Dq24eHcPVyTFuyj.wZ6oadNV1ze55tISHl VEnWkkaefp_Dn2224m0IWM57hWw5RAehJkpcXwtVvDCgvDZHvppP30W.1tIr n3M_eLF1sEne_uEIOecscoMqhErfef0BVkVFWEwWTXFN4ZqgyklKjENI0cpA 4G8Q.2jjdz8rC7yPHkD0ZzkQ4SSeP8UWOpAIaBfJnp.gqBOST7r3_51mHTuu 7nAzvizO99FG2gDy6bq_BZr8n2fpE7nYcATyr92foo7eXgnynA7fNdC.KOMk pUR0_2prDXUMa4.xBMGdFP.6rccHFE.Jbe72e3kT6._m5IeKRQVdM3D_gTSv tg-- X-Originating-IP: [64.170.98.32] Authentication-Results: mta1005.biz.mail.mud.yahoo.com from=ietf.org; domainkeys=neutral (no sig); from=ietf.org; dkim=neutral (no sig) Received: from 64.170.98.32 (EHLO mail.ietf.org) (64.170.98.32) by mta1005.biz.mail.mud.yahoo.com with SMTP; Fri, 25 Jun 2010 10:50:35 -0700 Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4D0128C155; Fri, 25 Jun 2010 10:45:04 -0700 (PDT) X-Original-To: i-d-announce@ietf.org Delivered-To: i-d-announce@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id EE83328C148; Fri, 25 Jun 2010 10:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D ACTION:draft-turner-ssl-must-not-01.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100625174501.EE83328C148@core3.amsl.com> Date: Fri, 25 Jun 2010 10:45:01 -0700 (PDT) X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: internet-drafts@ietf.org List-Id: Internet Draft Announcements only List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: i-d-announce-bounces@ietf.org Errors-To: i-d-announce-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Prohibiting SSL Version 3.0 and Earlier Author(s) : T. Polk, S. Turner Filename : draft-turner-ssl-must-not-01.txt Pages : 5 Date : 2010-6-25 This document requires that when TLS clients and servers establish connections that they never negotiate the use of Secure Sockets Layer (SSL) version 3.0 or earlier. In addition, this document recommends that TLS clients and servers not use TLS 1.0/SSL 3.1. This document updates the backward compatibility sections found in the Transport Security Layer (TLS) Protocol, RFC 5246. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-turner-ssl-must-not-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-turner-ssl-must-not-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-6-25103848.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --NextPart-- --------------010407070603030902050408-- From shuque@isc.upenn.edu Thu Jul 1 13:43:34 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 0D4463A691B for ; Thu, 1 Jul 2010 13:43:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.444 X-Spam-Level: X-Spam-Status: No, score=-2.444 tagged_above=-999 required=5 tests=[AWL=0.155, 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 ikHSPUvG75R8 for ; Thu, 1 Jul 2010 13:43:33 -0700 (PDT) Received: from talkeetna.isc-net.upenn.edu (TALKEETNA.isc-net.upenn.edu [128.91.197.188]) by core3.amsl.com (Postfix) with ESMTP id 2EB543A677C for ; Thu, 1 Jul 2010 13:43:33 -0700 (PDT) Received: by talkeetna.isc-net.upenn.edu (Postfix, from userid 4127) id C1B493057; Thu, 1 Jul 2010 16:43:44 -0400 (EDT) Date: Thu, 1 Jul 2010 16:43:44 -0400 From: Shumon Huque To: Peter Saint-Andre Message-ID: <20100701204344.GA28724@isc.upenn.edu> References: <4C2C0CF6.10608@stpeter.im> <4C2CB6E9.7080300@stpeter.im> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C2CB6E9.7080300@stpeter.im> User-Agent: Mutt/1.4.2.1i Organization: University of Pennsylvania Cc: certid@ietf.org Subject: Re: [certid] version -07 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, 01 Jul 2010 20:43:34 -0000 On Thu, Jul 01, 2010 at 09:40:25AM -0600, Peter Saint-Andre wrote: > Diffs are here: > > http://tools.ietf.org/rfcdiff?url2=draft-saintandre-tls-server-id-check-07.txt > > On 6/30/10 9:35 PM, Peter Saint-Andre wrote: > > Based on all the list feedback provided so far, I've pushed out a new > > version (-07) for your review: > > > > http://www.ietf.org/id/draft-saintandre-tls-server-id-check-07.txt In section 7.2. Informative References > [SIP-CERTS] > Gurbani, V., Lawrence, S., and B. Laboratories, "Domain > Certificates in the Session Initiation Protocol (SIP)", > draft-ietf-sip-domain-certs-06 (work in progress), > March 2010. the I-D reference needs to be replaced by RFC 5922. -- Shumon Huque University of Pennsylvania. From sm@resistor.net Thu Jul 1 16:14:09 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 451963A681D for ; Thu, 1 Jul 2010 16:14:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.176 X-Spam-Level: X-Spam-Status: No, score=-2.176 tagged_above=-999 required=5 tests=[AWL=0.423, 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 wVxzHSjHAQ3c for ; Thu, 1 Jul 2010 16:14:07 -0700 (PDT) Received: from ns1.qubic.net (ns1.qubic.net [208.69.177.116]) by core3.amsl.com (Postfix) with ESMTP id 31D6D3A6A92 for ; Thu, 1 Jul 2010 16:14:07 -0700 (PDT) Received: from SUBMAN.resistor.net ([10.0.0.1]) (authenticated bits=0) by ns1.qubic.net (8.14.5.Alpha0/8.14.5.Alpha0) with ESMTP id o61NE5EC026749 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 1 Jul 2010 16:14:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1278026055; x=1278112455; bh=/4PvyPXAhQm6QpYdhSEIZnRmSy2vc1ZdmTu2mZ9vCBU=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=21uAAZHQSWs36Pb+jeFWjEAWnKCfif0MyMTz5umhb1qK1fQRhf90ApYBd6/X3uka2 ye/cz16KSfyLxRIFsjWYszLsBMLae9D9L+Iy+793D3JNbq7w1u4aSuziMX9V08OBvE i0dARKpot+ZbOVC+6iKe9S/rMk/JbOfsaF8ZJ9RY= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1278026055; x=1278112455; bh=/4PvyPXAhQm6QpYdhSEIZnRmSy2vc1ZdmTu2mZ9vCBU=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=AcQtL6S0ogi97ueo7TWYBGaWnGBo4zrWUQ2sMKAeJOoyVdkcTYUOg/b/1LGn+wNS9 1HFkwP6hGENMGvQRQZSb3Mjhe66yz8np/3g21n3EfhbNuHP1M7zWYBLFfxNpMIAb7k avbhNq95bJlpFMH95DTSzJZzhF6WHPgaNvDh3AmY= DomainKey-Signature: a=rsa-sha1; s=mail; d=resistor.net; c=simple; q=dns; b=QSC56I6zgzc70x0rva/ym6lvVJSfd98XGBZOgdpTfcoyGIOiTrLZ036H7FY6xQtCj l7BwIm1+bJVsPVSEf9Sjoukvg/IVUGAWwlHNL3aNrUySB+4SEZMIuOU+C68MXT9baYo JPtXCYDpa/T0+YSoit/a/FTpCFJI44ebW0TyZZA= Message-Id: <6.2.5.6.2.20100701160552.0b7e5028@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 01 Jul 2010 16:13:38 -0700 To: Peter Saint-Andre From: SM In-Reply-To: <4C2BBEA1.1090506@stpeter.im> References: <20100612013249.GA4782@isc.upenn.edu> <4C2A65B5.4080209@stpeter.im> <20100630043158.GB26880@isc.upenn.edu> <07D9A6FC-C154-4125-AC33-45F2CE0C0374@apple.com> <4C2BA09F.8020908@stpeter.im> <4C2BBEA1.1090506@stpeter.im> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: certid@ietf.org Subject: Re: [certid] What DNS-ID if also using a DNS-SRV? 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, 01 Jul 2010 23:14:09 -0000 Hi Peter, At 15:01 30-06-10, Peter Saint-Andre wrote: >Here is a first draft... > >### > >2.1. Naming Applications > > This specification assumes that an Internet application is named > based on a DNS domain name (e.g., "example.com") -- supplemented in > some circumstances by an application type (e.g., "the IMAP server at > example.com"). Should that be application service instead of "Internet application"? Regards, -sm From Jeff.Hodges@KingsMountain.com Fri Jul 2 22:46: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 730563A657C for ; Fri, 2 Jul 2010 22:46:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.248 X-Spam-Level: X-Spam-Status: No, score=0.248 tagged_above=-999 required=5 tests=[AWL=-0.087, 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 znicpy1x4s5N for ; Fri, 2 Jul 2010 22:46:24 -0700 (PDT) Received: from cpoproxy1-pub.bluehost.com (cpoproxy1-pub.bluehost.com [69.89.21.11]) by core3.amsl.com (Postfix) with SMTP id A5A3D3A67B3 for ; Fri, 2 Jul 2010 22:46:23 -0700 (PDT) Received: (qmail 15088 invoked by uid 0); 3 Jul 2010 05:46:35 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by cpoproxy1.bluehost.com with SMTP; 3 Jul 2010 05:46:35 -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=Fr0lPRM7DfqqNuCWiAJvB4MCNmfvVnZUz3Z0kPRbcNx9a2fcIHJRjJOpNANbpItiuN+j16hwbdld4Wy8zfT5KQQR8GIwYYvgXzfLcxWnSs4epZeiBti4Zm7v5hfUIrFy; Received: from c-24-4-122-173.hsd1.ca.comcast.net ([24.4.122.173] helo=[192.168.11.10]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1OUvYh-00025P-BP for certid@ietf.org; Fri, 02 Jul 2010 23:46:35 -0600 Message-ID: <4C2ECEB6.7080209@KingsMountain.com> Date: Fri, 02 Jul 2010 22:46:30 -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 24.4.122.173 authed with jeff.hodges+kingsmountain.com} Subject: Re: [certid] version -07 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, 03 Jul 2010 05:46:27 -0000 As PaulH said ... finally decloaking after being off this topic for a while. Apologies for latency. Peter, thanks for updating the draft! All -- good discussion on the list, thanks for all the thoughtful contributions -- the spec is much better for it. Yes, I have various bits of feedback on -07, some described below. this is without a careful review though, and is driven by reading through the recent threads on certid@ and checking -07 for how the issues were addressed. I concur with the decisions taken. It seems that all raised issues were nominally addressed in -07, so the below are (subtle-but-important) nits. =JeffH ------ [ the below items aren't necessarily difficult to clean up, I'm just noting them for the record for now ] * It seems to me coming to this new revision of the spec somewhat "fresh", that the concepts being addressed could build more cleanly from (especially) section 1.1 (intro/motivation), section 2 Names, and section 3 Representation of Server Identity. I can take a whack at making concrete suggestions by early/mid this next week. * need to explicitly define (at least) the below terms/phrases in section 1.3 if we are going to use them.. attribute-type-and-value pair DER encoding Internet application ..or.. application service ..or.. ? service provider subjectAltName (this term is used in section 1.3 but isn't itself defined until seciton 2.2) * I think we need to review the terms/phrases we use to reference cert components and aspects thereof. I think we're being inconsistent and at times ambiguous (need to do careful review). unfortunately other specs we depend on use non-congruent terminology it seems. E.g. in just sections 2.2 and 3 we use these various terms/phrases wrt "subjectAltName"... subjectAltName extension subjectAltName extension types subjectAltNames subjectAltName entry SubjectAltName field subjectAltName identifier subjectAltName identifier types subjectAltName identifier of type [the GeneralName structure in] the subjectAltName ..and then including the rest of the spec we also use (in addition to the above).. application-specific subjectAltName extensions subjectAltName extension of type subjectAltName extensions of type Obviously various of the above terms/phrases are redundant and we ought to clean this up. --- end From Jeff.Hodges@KingsMountain.com Fri Jul 2 22:47:55 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 E6CA83A657C for ; Fri, 2 Jul 2010 22:47:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.302 X-Spam-Level: X-Spam-Status: No, score=-0.302 tagged_above=-999 required=5 tests=[AWL=0.474, BAYES_05=-1.11, 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 utBOFv-K5Qnz for ; Fri, 2 Jul 2010 22:47:52 -0700 (PDT) Received: from cpoproxy1-pub.bluehost.com (cpoproxy1-pub.bluehost.com [69.89.21.11]) by core3.amsl.com (Postfix) with SMTP id 9EFE13A6823 for ; Fri, 2 Jul 2010 22:47:47 -0700 (PDT) Received: (qmail 16152 invoked by uid 0); 3 Jul 2010 05:47:36 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by cpoproxy1.bluehost.com with SMTP; 3 Jul 2010 05:47:36 -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=LOhDF6noBvzJGGKpkPBWYoLXGTI/KVCfrxDXcEm6bxt/mWDk0byzPNFGWmOq9OPm1tm5PopOWa2L8YTAk2GDVOfJ3W2BTLkeLnRexGwJX0OOL+9AmAOd+GHR31gCrimB; Received: from c-24-4-122-173.hsd1.ca.comcast.net ([24.4.122.173] helo=[192.168.11.10]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1OUvZg-0002mw-D3 for certid@ietf.org; Fri, 02 Jul 2010 23:47:36 -0600 Message-ID: <4C2ECEF6.6060200@KingsMountain.com> Date: Fri, 02 Jul 2010 22:47:34 -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: quoted-printable X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 24.4.122.173 authed with jeff.hodges+kingsmountain.com} Subject: Re: [certid] Need to define "most specific RDN" 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, 03 Jul 2010 05:47:56 -0000 Peter Saint-Andre replied.. > > On 6/30/10 2:51 PM, Love H=F6rnquist =C5strand wrote: > >> Can you please add a DER encoded Name, the asn1parse/dump version of >> the name, and the LDAP version of string and annotation what the >> different parts are called, this confuses me every time I try to in >> parse the rfc's and drafts. > > I'm still just learning about all of these different terms, formats, > versions, and representations. And yes it is quite confusing. Perhaps > I'll ask one of the co-editors or contributors to come up with a good > example as you have requested... I can take a whack at doing that. =3DJeffH From Jeff.Hodges@KingsMountain.com Fri Jul 2 22:48:58 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 E5D5B3A6829 for ; Fri, 2 Jul 2010 22:48:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.074 X-Spam-Level: X-Spam-Status: No, score=-1.074 tagged_above=-999 required=5 tests=[AWL=1.191, BAYES_00=-2.599, 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 SWzyASIm62Vd for ; Fri, 2 Jul 2010 22:48:56 -0700 (PDT) Received: from cpoproxy2-pub.bluehost.com (cpoproxy2-pub.bluehost.com [67.222.39.38]) by core3.amsl.com (Postfix) with SMTP id 071383A6823 for ; Fri, 2 Jul 2010 22:48:55 -0700 (PDT) Received: (qmail 22893 invoked by uid 0); 3 Jul 2010 05:49:08 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by cpoproxy2.bluehost.com with SMTP; 3 Jul 2010 05:49:08 -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=AjTxU3RfeiWtXIc9o8/hHbFZ2W636A1LtzE7Ixypb/UplRKXJfl6mCm+2OSJr36iPfas+4v0HZuRr8J6atDBnRbAvGD9Az0QQWSGEXvlZ04o6xWiALh0j+4lpauFqOnw; Received: from c-24-4-122-173.hsd1.ca.comcast.net ([24.4.122.173] helo=[192.168.11.10]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1OUvbA-0003w1-3T for certid@ietf.org; Fri, 02 Jul 2010 23:49:08 -0600 Message-ID: <4C2ECF52.8070502@KingsMountain.com> Date: Fri, 02 Jul 2010 22:49:06 -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 24.4.122.173 authed with jeff.hodges+kingsmountain.com} Subject: Re: [certid] DC should be MUST NOT 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, 03 Jul 2010 05:48:58 -0000 Martin Rex postulated.. > > I assume the idea of the DC= components could be to establish something like > a hierarchical LDAP directory model based on DNS rather than assuming a > single global X.500 directory hierarchy and full-fledged DAP. Yes, in large part, that's the rationale behind the DC= components. =JeffH (a former LDAPv3 contributor and DNS-based directory hierarchy proponent) From Jeff.Hodges@KingsMountain.com Fri Jul 2 22:58:16 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 519EC3A67B3 for ; Fri, 2 Jul 2010 22:58:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.16 X-Spam-Level: X-Spam-Status: No, score=0.16 tagged_above=-999 required=5 tests=[AWL=-0.175, 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 s03LsUVIeXHh for ; Fri, 2 Jul 2010 22:58:13 -0700 (PDT) Received: from cpoproxy1-pub.bluehost.com (cpoproxy1-pub.bluehost.com [69.89.21.11]) by core3.amsl.com (Postfix) with SMTP id CAEDF3A672E for ; Fri, 2 Jul 2010 22:58:13 -0700 (PDT) Received: (qmail 25076 invoked by uid 0); 3 Jul 2010 05:58:26 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by cpoproxy1.bluehost.com with SMTP; 3 Jul 2010 05:58:26 -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=fAYIvlfr5b3jZWqvrUqJeQALFNKvOex4XouUe+5Lyw/uMTezWaJgd5GSGiOPmjv9aG+J6SjCm6gnfsaYZvw7YgCmke7VJSZW2FY+YPq1/GNGgz/PSZkmsnSt6m93Tzee; Received: from c-24-4-122-173.hsd1.ca.comcast.net ([24.4.122.173] helo=[192.168.11.10]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1OUvkA-0003RK-5r for certid@ietf.org; Fri, 02 Jul 2010 23:58:26 -0600 Message-ID: <4C2ED180.5080403@KingsMountain.com> Date: Fri, 02 Jul 2010 22:58:24 -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: quoted-printable X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 24.4.122.173 authed with jeff.hodges+kingsmountain.com} Subject: [certid] wrt domain names vs hostnames (was: Re: DC should be MUST NOT) 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, 03 Jul 2010 05:58:16 -0000 Martin Rex declared.. > > Paul Hoffman wrote: >> >> If you feel that way, fine. We have historically seen deployed PKIX >> implementations that got the order wrong because they had no certs >> to test with. I do not hold it against someone to get the order wrong= , >> particularly because all of the text examples in RFC 5280 say >> "dc=3Dexample,dc=3Dcom". > > You're right on the spot -- all of the DC=3D examples in rfc-5280 are > purely about >>domain name<<. There is also a server mentioned > "ldap.example.com", but there is not a single example in rfc-5280 > that puts a >>hostname<< into a DC component. However, there is a explicit, and to-some-degree-formally acknowledged,=20 disagreement over whether there are salient differences (today) between=20 "hostnames" and "domain names". I just want to point this out because I only recently became aware of it = while=20 working on -server-id-check- and -strict-transport-sec- and I think it is= =20 something many of us should be aware of, however I don't think re-opening= such=20 a discussion is appropriate for the certid@ list. The acknowledged disagreement is buried in RFC3490 [1] in its terminology= =20 section (emphasis added).. [STD13] talks about "domain names" and "host names", but many people use the terms interchangeably. Further, because [STD13] was not terribly clear, >>> many people who are sure they know the exact <<< >>> definitions of each of these terms disagree on the definitions. <<<= In this document the term "domain name" is used in general. This document explicitly cites [STD3] whenever referring to the host name syntax restrictions defined therein. A significant portion of the discussion that led to the above posture is = documented in this thread=20 (from bac= k in=20 2001) rooted here... [idn] hostname history hell http://www.ops.ietf.org/lists/idn/idn.2001/msg02989.html And here's Patrik F=E4ltstr=F6m's contribution/statement to the thread wh= ich seems=20 to presage the above-cited rfc3490 language.. http://www.ops.ietf.org/lists/idn/idn.2001/msg03048.html =3DJeffH [1] "Internationalizing Domain Names in Applications (IDNA)" RFC3490 http://www.ietf.org/rfc/rfc3490.txt From ietf-certid@velox.ch Sun Jul 4 02:59:55 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 8D9EF3A685B for ; Sun, 4 Jul 2010 02:59:55 -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 lEC5LKxZA34o for ; Sun, 4 Jul 2010 02:59:53 -0700 (PDT) Received: from appendix.velox.ch (appendix.velox.ch [62.75.148.60]) by core3.amsl.com (Postfix) with ESMTP id 4E7DC3A63EC for ; Sun, 4 Jul 2010 02:59:50 -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 o649xmHd021623 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sun, 4 Jul 2010 11:59:49 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=velox.ch; s=appendix-177f; t=1278237589; bh=7mPCZsfXeos+h3Zj8F/Mrkd7/AQ39qEwZ3sbrRP9taY=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=ltC0xvOpvBZDPaRhnofx23AjASiLP7onAt/+GPQ0XZPQUqad3h0qxrfx4QvB/b8MY hkEibYq26pJi2AgDmgyy/iDLhZvY2hQN0Rf8TS+XRxBZuhLo0ovLeiuhLj5FOS3fQs 6J6USTEau71K1mYVk3ebRXnEtLa/q2i/s/au07R6pQTIGGQu+e3HPstrxyyKSHZmLd aMgvGvbU6pkHFyHTUCHMiD/yQWzrUrbbuvx1XZqPq3NrOOUNkvC8OH85jeyY1Jg88y dZigZASvcFP/aK7yZKZoTqsFN2Q670psk6HuyuzIdxeFO996NHgyydoxOtl0YG3v6a Bg5V+3rP75+4Q== Message-ID: <4C305B93.9090001@velox.ch> DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=velox.ch; s=cortex-8a58; t=1278237588; bh=7mPCZsfXeos+h3Zj8F/Mrkd7/AQ39qEwZ3sbrRP9taY=; h=Date:From:MIME-Version:To:Subject:References:In-Reply-To: Content-Type:Content-Transfer-Encoding; b=Kw+dDlz1qVYZn2dbAcObDOuZJmcTyOR7gWUZ/IeSMfnVIrTdTxRh3xJgut+Y+ADUe pEL1Z6dkhRylKUIbLp3qHWFVDYy66h5ZCN4yG8yD+/N8RKdq6yXArmIzcRp2S6Mu9J DUk9q8TPGOqJ+KkbHKciGy43Wzw5PfXg2k/93ba+DTLUoekYS9ApYnFsGA43dcZU6V 3+7/AOaBBbGVNpiOUUJlm+atKHR4/ie1bCzHHf51TqrHUJV1JiQtLJsSwFkryjpszs VrEb62gYJ8e/Z0UMnKKnb9t0/qwPA6DfIqRDz2g9cys6ETnMCmvzRDhznTBO92J1YY SNcFS0syRA9Fg== Date: Sun, 04 Jul 2010 11:59:47 +0200 From: Kaspar Brand User-Agent: Thunderbird/3.0 MIME-Version: 1.0 To: certid@ietf.org References: <201006301746.o5UHkIsE019133@fs4113.wdf.sap.corp> <4C2B843A.5010206@stpeter.im> In-Reply-To: <4C2B843A.5010206@stpeter.im> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [certid] Need to define "most specific RDN" 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: Sun, 04 Jul 2010 09:59:55 -0000 On 30.06.2010 19:51, Peter Saint-Andre wrote: > On 6/30/10 11:46 AM, Martin Rex wrote: >> I'm actually confused by refering to one end with "most significant" and >> the other with "most specific". Couldn't we just drop the "most significant" >> entirely and use "least specific" / "most specific" for the two ends? > > Given that we never use the term "most significant" in this I-D, I'd say > we can remove any mention of it. I would definitely recommend that. It's still present in two places in -07, though: > 2.2. Subject Naming in PKIX Certificates > > [...] In the DER encoding > of a DN, the RDNs are always in order from most significant to least > significant (i.e., the first RDN is most significant and the last RDN > is least significant); however, in the string representation of a DN > as used in various protocols and data formats, the RDNs might be > ordered from most significant to least significant (e.g., this is > true of LDAP) or from least significant to most significant. > 3.1.3. Server Identity Check > > [...] For example, some X.500 > implementations order the RDNs in a DN using a left-to-right (most > significant to least significant) convention instead of LDAP's right- > to-left convention. After another look at X.501 and some of the LDAP RFCs (2247 in particular), I'm getting to the conclusion that the "most specific vs. most significant" distinction is actually a construct which mainly originates from / applies to the DNS world - and through various RFCs (among them 2818) somehow made its way into the PKIX world... but it doesn't seem that for a "classic" X.500 DN there is really a notion of "most/least specific". [1] Section 2.2 in -07 also has > Because a DN is an ordered sequence, order is preserved in the string > representation of a DN. However, because an RDN is an unordered > group of attribute-type-and-value pairs, the string representation of > an RDN can differ from the canonical DER encoding; in the canonical > encoding, the RDN that is deepest in the tree (and that therefore > distinguishes the relative name) is called the "most specific" RDN. I don't quite understand what you mean by "in the canonical encoding, the RDN that is deepest in the tree" - I think the second sentence is about the (canonical) encoding of an RDN, and an RDN itself can't have a "most specific" RDN, obviously... In any case, using both "specific" and "significant" (and mixing in "most" and "least") in the text is definitely confusing, as pointed out by Martin. Let's stick to one, at most. Kaspar [1] Re-reading section 3.1 in RFC 2818 can actually confirm this hypothesis, under the following interpretation: "the (most specific) Common Name field in the Subject field of the certificate MUST be used" can be understood to mean the domain name which has the highest number of DNS labels: if the subject has CN=foo.example.net and CN=example.net, then the first one must be used for the identity check (it's more specific than CN=example.net), irrespective of its position in the DER encoded subject, actually. From ietf-certid@velox.ch Sun Jul 4 03:17: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 15FED3A685B for ; Sun, 4 Jul 2010 03:17:35 -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 AolBukBUFc3n for ; Sun, 4 Jul 2010 03:17:34 -0700 (PDT) Received: from appendix.velox.ch (appendix.velox.ch [62.75.148.60]) by core3.amsl.com (Postfix) with ESMTP id C644E3A67CF for ; Sun, 4 Jul 2010 03:17:33 -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 o64AHWnD028320 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sun, 4 Jul 2010 12:17:33 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=velox.ch; s=appendix-177f; t=1278238653; bh=209nvRl44JS8aILevjzjDT4uLxnF/r5uYhMTXhEgsDo=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=okxEf08HG0AAMutOLuzGkJeMweReXhnpvW4sIOnKzKkgjXPX9/0ZNO5MoSbMFEG3g dK+gp3eZGGCKznd87Jg9hXsk1JomEbnq2y/hw/d9uUzkF1KmP5sUEVo7t0z8POWj0R vWsU2EMcjqycLmjCZCsr+WUG43zm0vKWUomwGGtTZ9k81WChaYTfb2esXwjVsnD6hj YljH/eVrpPzz0B8r1eSUEoQ8pqYxt614UNoHQwledSYMENA9Kc5M7xhwqj9jKn71kO MXIxotzlTTzJmUDU9XpsUal2g6z/3yhCgIC2apnDK/k8QbOL6nkSIZnapTfV9kv26S 638PfqbNUlSvA== Message-ID: <4C305FBC.4040302@velox.ch> DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=velox.ch; s=cortex-8a58; t=1278238652; bh=209nvRl44JS8aILevjzjDT4uLxnF/r5uYhMTXhEgsDo=; h=Date:From:MIME-Version:To:Subject:References:In-Reply-To: Content-Type:Content-Transfer-Encoding; b=rWtHNS+kFwSvfjHVb018VQK4yZjBtY8TlGHhaaMG1CyrAYPic07G0C08/EHq3+L4/ QbzwG5IkJySTSwHFD+fg3WbtD0Ps1DEhpTgwILIrzrJxfrWHh2U0HFu55EFyJyAtPd OoLvKh7EXSJUb861psT6j5J1zlgwowR0ncsIIyUVVYkNe1dS381mjR+Sa7YQ0uZFMb y0XDnTNpXjnS1b/uFkvOtWEXgcqKRIxQwyYaRNW+vwOuPmfQsNy5qTq8WtofGe3LF/ cQqTUX+hscVRrKOssHhlrFpzc9P1JZKjFvxal/+ghzQPv4bAkYzN1/5LLtEEevxHup 9MX5rc9NkGVyA== Date: Sun, 04 Jul 2010 12:17:32 +0200 From: Kaspar Brand User-Agent: Thunderbird/3.0 MIME-Version: 1.0 To: certid@ietf.org References: <4C2ECEB6.7080209@KingsMountain.com> In-Reply-To: <4C2ECEB6.7080209@KingsMountain.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [certid] version -07 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: Sun, 04 Jul 2010 10:17:35 -0000 On 03.07.2010 07:46, =JeffH wrote: > * I think we need to review the terms/phrases we use to reference cert > components and aspects thereof. I think we're being inconsistent and at times > ambiguous (need to do careful review). unfortunately other specs we depend on > use non-congruent terminology it seems. > > E.g. in just sections 2.2 and 3 we use these various terms/phrases wrt > "subjectAltName"... > > subjectAltName extension > > subjectAltName extension types > > subjectAltNames > > subjectAltName entry > > SubjectAltName field > > subjectAltName identifier > > subjectAltName identifier types > > subjectAltName identifier of type > > [the GeneralName structure in] the subjectAltName > > > ..and then including the rest of the spec we also use (in addition to the above).. > > application-specific subjectAltName extensions > > subjectAltName extension of type > > subjectAltName extensions of type > > > Obviously various of the above terms/phrases are redundant and we ought to > clean this up. Agreed. My earlier suggestion ("subjectAltName entry") is mainly due to the following statement in RFCs 2459/3280/5280: If the subjectAltName extension is present, the sequence MUST contain at least one entry. "Extension" is actually the term for the whole container - i.e., I would refrain from using wording like "subjectAltName extension of type X" (or even "subjectAltName extensions", because a particular extension is only allowed to occur once, as per RFCs 2459/3280/5280). Also, "subjectAltNames" seems rather sloppy as a term, IMO. Kaspar From ludwig.nussel@suse.de Tue Jul 6 05:33:28 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 565F03A6831 for ; Tue, 6 Jul 2010 05:33:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.649 X-Spam-Level: X-Spam-Status: No, score=-103.649 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_DE=0.35, 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 uchJ4+fDCd7z for ; Tue, 6 Jul 2010 05:33:27 -0700 (PDT) Received: from mx2.suse.de (cantor2.suse.de [195.135.220.15]) by core3.amsl.com (Postfix) with ESMTP id 33ED53A6887 for ; Tue, 6 Jul 2010 05:33:27 -0700 (PDT) Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.221.2]) by mx2.suse.de (Postfix) with ESMTP id BB77187567 for ; Tue, 6 Jul 2010 14:33:28 +0200 (CEST) From: Ludwig Nussel To: certid@ietf.org Date: Tue, 6 Jul 2010 14:35:29 +0200 User-Agent: KMail/1.13.3 (Linux/2.6.34-9-desktop; KDE/4.4.3; x86_64; ; ) References: <201006301746.o5UHkIsE019133@fs4113.wdf.sap.corp> <4C2B843A.5010206@stpeter.im> <4C305B93.9090001@velox.ch> In-Reply-To: <4C305B93.9090001@velox.ch> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201007061435.29786.ludwig.nussel@suse.de> Subject: Re: [certid] Need to define "most specific RDN" 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, 06 Jul 2010 12:33:28 -0000 Kaspar Brand wrote: > [1] Re-reading section 3.1 in RFC 2818 can actually confirm this > hypothesis, under the following interpretation: "the (most specific) > Common Name field in the Subject field of the certificate MUST be used" > can be understood to mean the domain name which has the highest number > of DNS labels: if the subject has CN=foo.example.net and CN=example.net, > then the first one must be used for the identity check (it's more > specific than CN=example.net), irrespective of its position in the DER > encoded subject, actually. That interpretation at least doesn't require knowledge about certificate encoding subtleties. It's ambiguous though. You could have several CN with an equal number of dots after all. Just think of this one: http://www.mail-archive.com/openssl-users@openssl.org/msg61198.html cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) From peter.sylvester@edelweb.fr Tue Jul 6 09:42:16 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 B23073A67C0 for ; Tue, 6 Jul 2010 09:42:16 -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 YcFHEVRHuo4Q for ; Tue, 6 Jul 2010 09:42:15 -0700 (PDT) Received: from ganymede.on-x.com (ganymede.on-x.com [92.103.215.11]) by core3.amsl.com (Postfix) with ESMTP id 2BCC33A63C9 for ; Tue, 6 Jul 2010 09:42:15 -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 A8990170 for ; Tue, 6 Jul 2010 18:42:16 +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 93B6D17048 for ; Tue, 6 Jul 2010 18:42:16 +0200 (CEST) Received: from [192.168.0.14] (gut75-3-82-227-163-182.fbx.proxad.net [82.227.163.182]) by smtps.on-x.com (Postfix) with ESMTP id 0E43C782B for ; Tue, 6 Jul 2010 18:42:15 +0200 (CEST) Message-ID: <4C335CE5.1090608@edelweb.fr> Date: Tue, 06 Jul 2010 18:42:13 +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: <201006301746.o5UHkIsE019133@fs4113.wdf.sap.corp> <4C2B843A.5010206@stpeter.im> <4C305B93.9090001@velox.ch> <201007061435.29786.ludwig.nussel@suse.de> In-Reply-To: <201007061435.29786.ludwig.nussel@suse.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [certid] Need to define "most specific RDN" 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, 06 Jul 2010 16:42:16 -0000 On 07/06/2010 02:35 PM, Ludwig Nussel wrote: > Kaspar Brand wrote: > >> [1] Re-reading section 3.1 in RFC 2818 can actually confirm this >> hypothesis, under the following interpretation: "the (most specific) >> Common Name field in the Subject field of the certificate MUST be used" >> can be understood to mean the domain name which has the highest number >> of DNS labels: if the subject has CN=foo.example.net and CN=example.net, >> then the first one must be used for the identity check (it's more >> specific than CN=example.net), irrespective of its position in the DER >> encoded subject, actually. >> > That interpretation at least doesn't require knowledge about > certificate encoding subtleties. It's ambiguous though. You could > have several CN with an equal number of dots after all. Just think > of this one: > http://www.mail-archive.com/openssl-users@openssl.org/msg61198.html > > cu > Ludwig > > X.500 defines a tree structure, the nodes are relative names put into a hierarchie represented by a DN. a prefix of the elements in the sequence defines thus a "subtree", and the relative name of a leaf is the rightmost element, In a tree the most specific element a leaf and moving backwards defined less specific. There is no need at all to talk about binary encoding, or DER or whatever. A DN is a sequence of relative names forming a tree structure when interpreted in the X.500 context. This is thus one clear interpretation of 'most specific' (for a RDN). But: Since RDN can have multiple occurences of AVAs with the same type, (and one my even construct interpretations as above) it is not clear whether anything else than putting exactly one AVA with type Common Name into the very last component and not having any AVA with type Common name may lead to unexpected results, making 2818 unclear. At least I think one can agree that Common name in the last RDN as the only AVA is "safe". What can one do else: - some other RDNs without after it? probably ok, but not sure. - other RDNs with Common Name before? oh oh, like th \0 attack - multiple AVAs in the same RDN. maybe. ... Anyway, since there is no good reason not to put a subjectAltName, I do not think that one shouls say anything more than "If you use a Common Name other than in the most simple case one may run a risk not to be interpreted correctly." replace: 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]..... and so on by In essence, Subject (and Issuer) are essentially are defined in PKIX and X.50x/ISOnnnn as ASN.1 type DistinguishedName which is (in ASN.1 terms) a a row of elements (SEQUENCE OF in ASN.1 terms) of type RelativeDistinguishedName (RDN). In the directory context and in the PKIX context this defines a hierarchical tree structure from left to right and least to most specific, i.e. a prefix defines a subtree and the relative name of a leaf is the rightmost one in the sequence. An RDN is a collection (SET OF in ASN.1 terms) of elements of the ASN.1 type AttributeValueAssertion (AVA). ... leaving as exercise a definition of AVA. Thus, regarding this, the usage of "most specific RDN of type Common Name" in HTTPS is not precise enough. Furthermore, string representations (as well as graphical ones) may confuse users because of two possible interpretations of an implied order of RDNs. e.g. LDAP define the order .... and, historically, Openssl uses the other direction. By the way: Certificates are not binary objects. At best: Certificates are structures defined as ASN.1 types, and (almost always) transmitted in an encoding called DER... which may be encapsulated in base64, i.e. becoming textual ... etc. Anyway, does this matter here? Compare: The last paragraph of 2.2 doesn't use DER. SubjectAltname is not a 'field', it is an occurence of type Extension identified (... let's say ... ) as SunjectAltName. Certificate subjects may have alternate names represented as Extension identified as SubjectAltName. Thus: 2.2 can be greatly simplified IMO. ave fun. From peter.sylvester@edelweb.fr Tue Jul 6 10:33: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 BBC183A682B for ; Tue, 6 Jul 2010 10:33:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, 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 Z+rK-w+CG7yP for ; Tue, 6 Jul 2010 10:33:47 -0700 (PDT) Received: from ganymede.on-x.com (ganymede.on-x.com [92.103.215.11]) by core3.amsl.com (Postfix) with ESMTP id D4D593A6979 for ; Tue, 6 Jul 2010 10:33:46 -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 89C0E149 for ; Tue, 6 Jul 2010 19:33:48 +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 8A2E717048 for ; Tue, 6 Jul 2010 19:33:47 +0200 (CEST) Received: from [192.168.0.14] (gut75-3-82-227-163-182.fbx.proxad.net [82.227.163.182]) by smtps.on-x.com (Postfix) with ESMTP id 705EF782B for ; Tue, 6 Jul 2010 19:33:47 +0200 (CEST) Message-ID: <4C3368FA.3080109@edelweb.fr> Date: Tue, 06 Jul 2010 19:33: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 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [certid] chapter 4.4.5 ... 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, 06 Jul 2010 17:33:47 -0000 says the client MAY as a fallback check for a fully-qualified DNS domain name in the last Common Name RDN in the sequence of RDNs making up the Distinguished Name within the certificate's subjectName (where 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). The text in parenthesis 'refers to the order of the ASN.1 sequence' the last half sentence is superfluous. 'Common Name RDN' is not the correct term (as already explained by many). The text 'In existing certficates ..' stars with a defintion which should rather belong to 2.2. A clear separation of 2.2 and 4.4 should be done. There is also redundancy with 4.3 and 4.4.4 In one it is a security note, the other is not. at least the same things are said (at least) twice. From ietf-certid@velox.ch Tue Jul 6 23:42:56 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 3ADAA3A68AC for ; Tue, 6 Jul 2010 23:42:56 -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 6ja9H8RAetrV for ; Tue, 6 Jul 2010 23:42:53 -0700 (PDT) Received: from appendix.velox.ch (appendix.velox.ch [62.75.148.60]) by core3.amsl.com (Postfix) with ESMTP id 781B43A68B1 for ; Tue, 6 Jul 2010 23:42:46 -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 o676fsra025930 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 7 Jul 2010 08:41:55 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=velox.ch; s=appendix-177f; t=1278484915; bh=ZSeNzRiKHYm4pyhN8EshZ5qtghjmlIYGrL0GhxoUoUM=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=LRzgq16ZN+qJGkKl4vbHufgk+G7VnEd0QKzya954weAtYcfHuOEmKEO3gYhDJaDok O4DADDnvXixCrWagEebZatt5KpG9pIDUTGoKuvyRhZxNwmv5GXurIGCNqD0dymdcK/ cw2CaxAtxj7RifX8bhRvvQINF6cXUmjQnto3/JBcHe/170tWl7vPd3bi57MRePImzq oTi8amDhtWUXY+JMvB6xucBrA4NM28bj4oFZkIIU10USQgFE82wHEjlrx9+gU5mBiF EYX9WHahktxRXR0n0YJy1aFP3I4Sb0HmelYwImpBERRPEXq64QElHs9bvFih/0JUML JkZz1QryRB44g== Message-ID: <4C3421B3.3070404@velox.ch> DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=velox.ch; s=cortex-8a58; t=1278484914; bh=ZSeNzRiKHYm4pyhN8EshZ5qtghjmlIYGrL0GhxoUoUM=; h=Date:From:MIME-Version:To:Subject:References:In-Reply-To: Content-Type:Content-Transfer-Encoding; b=MDbjAo0j+BPMuZ6KQ3etSUUggd9/GkD++FJDrKljoBCfjmiX6EnhqYWIN73OCEJt9 IVw0MNKvmNxMBMUAZJwtKNrjYQ1cOf+mU4Rf04LAK2n/0YH3UApPX9lotcb2QN1css uGqkie4HHVTS2erDLG4wy4/gJyo8KyegQ8pLyuZDZyPzyOTz6MPuAXsadlE2P9j0Zc Qn8t6Z/dDiU7Br0dEWL+9s6VpW4Es3Hn6XmGkKTEJM6rvJ+Pb0gCYJoXM7z5idz0oX mFEqNwp5wLCWw3cxjZa+ciw5+qZSOIQ9qgCgavQflXbbZAGmoW+d9XzQeWhQJevBdF cN+6ZUKUw1PUQ== Date: Wed, 07 Jul 2010 08:41:55 +0200 From: Kaspar Brand User-Agent: Thunderbird/3.x MIME-Version: 1.0 To: certid@ietf.org References: <201006301746.o5UHkIsE019133@fs4113.wdf.sap.corp> <4C2B843A.5010206@stpeter.im> <4C305B93.9090001@velox.ch> <201007061435.29786.ludwig.nussel@suse.de> <4C335CE5.1090608@edelweb.fr> In-Reply-To: <4C335CE5.1090608@edelweb.fr> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [certid] Need to define "most specific RDN" 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, 07 Jul 2010 06:42:56 -0000 On 06.07.2010 18:42, Peter Sylvester wrote: > X.500 defines a tree structure, the nodes are relative names put > into a hierarchie represented by a DN. a prefix of the elements in > the sequence defines thus a "subtree", and the relative name of a leaf > is the rightmost element, In a tree the most specific element a leaf > and moving backwards defined less specific. > > There is no need at all to talk about binary encoding, or DER or > whatever. A DN is a sequence of relative names forming a tree > structure when interpreted in the X.500 context. This is thus > one clear interpretation of 'most specific' (for a RDN). I don't think that this is the issue here - it's the wording in RFC 2818 which is the source of all this... well, I'd say, mess: 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. Matching is performed using the matching rules specified by [RFC2459]. If more than one identity of a given type is present in the certificate (e.g., more than one dNSName name, a match in any one of the set is considered acceptable.) Reading "(most specific) Common Name field" as "Common Name in the most specific RDN" is one interpretation, but I'm not sure if it's the only one. And given the attention this issue received on the list so far, it also seems somewhat ironic that this "requirement" is only appearing in parentheses in an RFC which happens to be informational only, BTW... > Anyway, since there is no good reason not to put a subjectAltName, > I do not think that one shouls say anything more than > "If you use a Common Name other than in the most simple case one > may run a risk not to be interpreted correctly." A BCP document should say more that just state how implementations currently behave, I think [1]. Leaving that "most specific", peculiar requirement from RFC 2818 aside, I don't believe that there are really strong arguments against treating multiple CNs in the subject different from a subjectAltName extension with multiple dNSName entries - why not consider "a match in any one of the set[s]" acceptable...? [2] Clarifying/fixing that blurry "(most specific)" statement from RFC 2818 would be highly desirable for the new BCP, IMO. If by this we can get away with a term whose meaning isn't intuitively clear (compare this e.g. to "left-most DNS label"), then I would definitely consider that a plus. Kaspar [1] From RFC 2026: a BCP document [...] is a vehicle by which the IETF community can define and ratify the community's best current thinking on a statement of principle or on what is believed to be the best way to perform some operations or IETF process function." [2] I'm aware of Nelson's message at http://www.ietf.org/mail-archive/web/certid/current/msg00115.html, but am wondering to how many CAs the statement about unvetted CNs really applies. In my sample from 2009, the multi-CN certs (211 out of ~90,000) are basically limited to one of the so-called "commercial CAs", and I'm pretty sure that this CA does (/claims to) vet all CNs... what they actually do is mirror the entries from the subjectAltName extension in the subject DN. (It happens to be the same CA as the one appearing in the message referenced by Ludwig, for the sake of completeness.) From stpeter@stpeter.im Fri Jul 9 11:52:53 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 57E073A672E for ; Fri, 9 Jul 2010 11:52:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.735 X-Spam-Level: X-Spam-Status: No, score=-2.735 tagged_above=-999 required=5 tests=[AWL=-0.136, 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 PQuc8c80qDCe for ; Fri, 9 Jul 2010 11:52:51 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id DC5793A6AA3 for ; Fri, 9 Jul 2010 11:52:51 -0700 (PDT) Received: from dhcp-64-101-72-121.cisco.com (dhcp-64-101-72-121.cisco.com [64.101.72.121]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 1508740E4B; Fri, 9 Jul 2010 12:52:57 -0600 (MDT) Message-ID: <4C377007.4090308@stpeter.im> Date: Fri, 09 Jul 2010 12:52:55 -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: SM References: <20100612013249.GA4782@isc.upenn.edu> <4C2A65B5.4080209@stpeter.im> <20100630043158.GB26880@isc.upenn.edu> <07D9A6FC-C154-4125-AC33-45F2CE0C0374@apple.com> <4C2BA09F.8020908@stpeter.im> <4C2BBEA1.1090506@stpeter.im> <6.2.5.6.2.20100701160552.0b7e5028@resistor.net> In-Reply-To: <6.2.5.6.2.20100701160552.0b7e5028@resistor.net> X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: certid@ietf.org Subject: Re: [certid] What DNS-ID if also using a DNS-SRV? 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, 09 Jul 2010 18:52:53 -0000 On 7/1/10 5:13 PM, SM wrote: > Hi Peter, > At 15:01 30-06-10, Peter Saint-Andre wrote: >> Here is a first draft... >> >> ### >> >> 2.1. Naming Applications >> >> This specification assumes that an Internet application is named >> based on a DNS domain name (e.g., "example.com") -- supplemented in >> some circumstances by an application type (e.g., "the IMAP server at >> example.com"). > > Should that be application service instead of "Internet application"? Yes, I've changed that to: ### 2. Names This section discusses naming of application services on the Internet, followed by a brief tutorial about subject naming in PKIX. 2.1. Naming Application Services This specification assumes that the name of an application service is based on a DNS domain name (e.g., "example.com") -- supplemented in some circumstances by an application type (e.g., "the IMAP server at example.com"). ### Peter -- Peter Saint-Andre https://stpeter.im/ From stpeter@stpeter.im Fri Jul 9 12:21:39 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 DA4143A67E5 for ; Fri, 9 Jul 2010 12:21:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.731 X-Spam-Level: X-Spam-Status: No, score=-2.731 tagged_above=-999 required=5 tests=[AWL=-0.132, 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 E8a8XArvwgQn for ; Fri, 9 Jul 2010 12:21:39 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id E43E23A67C0 for ; Fri, 9 Jul 2010 12:21:38 -0700 (PDT) Received: from dhcp-64-101-72-121.cisco.com (dhcp-64-101-72-121.cisco.com [64.101.72.121]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id E014D40E4B for ; Fri, 9 Jul 2010 13:21:43 -0600 (MDT) Message-ID: <4C3776C6.80707@stpeter.im> Date: Fri, 09 Jul 2010 13:21:42 -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: <4C3368FA.3080109@edelweb.fr> In-Reply-To: <4C3368FA.3080109@edelweb.fr> X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [certid] chapter 4.4.5 ... 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, 09 Jul 2010 19:21:39 -0000 On 7/6/10 11:33 AM, Peter Sylvester wrote: > says > > the client MAY as a fallback > check for a fully-qualified DNS domain name in the last Common Name > RDN in the sequence of RDNs making up the Distinguished Name within > the certificate's subjectName (where 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). > > > The text in parenthesis 'refers to the order of the ASN.1 sequence' > the last half sentence is superfluous. Agreed. I've deleted that text so that we discuss ordering issues only in the section about subject naming. > 'Common Name RDN' is not the correct term (as already explained > by many). Changed to CN-ID so that we reference the definition provided earlier in the document. > The text 'In existing certficates ..' stars with a defintion which > should rather belong to 2.2. A clear separation of 2.2 and 4.4 > should be done. Done. > There is also redundancy with 4.3 and 4.4.4 In one it is > a security note, the other is not. at least the same things are > said (at least) twice. That repetition was intentional. Peter -- Peter Saint-Andre https://stpeter.im/ From stpeter@stpeter.im Fri Jul 9 12:40:29 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 48B293A6881 for ; Fri, 9 Jul 2010 12:40:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.727 X-Spam-Level: X-Spam-Status: No, score=-2.727 tagged_above=-999 required=5 tests=[AWL=-0.128, 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 4-i2dWbKeTmc for ; Fri, 9 Jul 2010 12:40:28 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 28AEC3A684B for ; Fri, 9 Jul 2010 12:40:28 -0700 (PDT) Received: from dhcp-64-101-72-121.cisco.com (dhcp-64-101-72-121.cisco.com [64.101.72.121]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 4F9A940E4B for ; Fri, 9 Jul 2010 13:40:33 -0600 (MDT) Message-ID: <4C377B30.2000202@stpeter.im> Date: Fri, 09 Jul 2010 13:40:32 -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: <4C2ECEB6.7080209@KingsMountain.com> <4C305FBC.4040302@velox.ch> In-Reply-To: <4C305FBC.4040302@velox.ch> X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [certid] version -07 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, 09 Jul 2010 19:40:29 -0000 On 7/4/10 4:17 AM, Kaspar Brand wrote: > On 03.07.2010 07:46, =JeffH wrote: >> * I think we need to review the terms/phrases we use to reference cert >> components and aspects thereof. I think we're being inconsistent and at times >> ambiguous (need to do careful review). unfortunately other specs we depend on >> use non-congruent terminology it seems. >> >> E.g. in just sections 2.2 and 3 we use these various terms/phrases wrt >> "subjectAltName"... >> >> subjectAltName extension >> >> subjectAltName extension types >> >> subjectAltNames >> >> subjectAltName entry >> >> SubjectAltName field >> >> subjectAltName identifier >> >> subjectAltName identifier types >> >> subjectAltName identifier of type >> >> [the GeneralName structure in] the subjectAltName >> >> >> ..and then including the rest of the spec we also use (in addition to the above).. >> >> application-specific subjectAltName extensions >> >> subjectAltName extension of type >> >> subjectAltName extensions of type >> >> >> Obviously various of the above terms/phrases are redundant and we ought to >> clean this up. > > Agreed. My earlier suggestion ("subjectAltName entry") is mainly due to > the following statement in RFCs 2459/3280/5280: > > If the subjectAltName extension is present, the sequence MUST contain > at least one entry. > > "Extension" is actually the term for the whole container - i.e., I would > refrain from using wording like "subjectAltName extension of type X" (or > even "subjectAltName extensions", because a particular extension is only > allowed to occur once, as per RFCs 2459/3280/5280). Also, > "subjectAltNames" seems rather sloppy as a term, IMO. I've fixed these terminological confusions. We now use only two terms: - subjectAltName extension (which can contain multiple entries) - subjectAltName entry (a specific entry of type dNSName, SRVName, etc.) Peter -- Peter Saint-Andre https://stpeter.im/ From stpeter@stpeter.im Mon Jul 12 07:52:03 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 0BBE93A698C for ; Mon, 12 Jul 2010 07:52:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.862 X-Spam-Level: X-Spam-Status: No, score=-2.862 tagged_above=-999 required=5 tests=[AWL=-0.262, 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 Ln5XpbBrb6aU for ; Mon, 12 Jul 2010 07:52:01 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 79DAD3A6990 for ; Mon, 12 Jul 2010 07:52: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 D6A1740E44 for ; Mon, 12 Jul 2010 08:52:08 -0600 (MDT) Message-ID: <4C3B2C16.7000209@stpeter.im> Date: Mon, 12 Jul 2010 08:52:06 -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: <4C2ECEB6.7080209@KingsMountain.com> In-Reply-To: <4C2ECEB6.7080209@KingsMountain.com> X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [certid] version -07 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, 12 Jul 2010 14:52:03 -0000 On 7/2/10 11:46 PM, =JeffH wrote: > As PaulH said ... finally decloaking after being off this topic for a > while. Apologies for latency. > > Peter, thanks for updating the draft! > > All -- good discussion on the list, thanks for all the thoughtful > contributions -- the spec is much better for it. > > Yes, I have various bits of feedback on -07, some described below. this > is without a careful review though, and is driven by reading through the > recent threads on certid@ and checking -07 for how the issues were > addressed. I concur with the decisions taken. It seems that all raised > issues were nominally addressed in -07, so the below are > (subtle-but-important) nits. > > =JeffH > ------ > > [ the below items aren't necessarily difficult to clean up, I'm just > noting them for the record for now ] > > * It seems to me coming to this new revision of the spec somewhat > "fresh", that the concepts being addressed could build more cleanly from > (especially) section 1.1 (intro/motivation), section 2 Names, and > section 3 Representation of Server Identity. I can take a whack at > making concrete suggestions by early/mid this next week. That sounds nice but not necessary. :) > * need to explicitly define (at least) the below terms/phrases in > section 1.3 if we are going to use them.. > > attribute-type-and-value pair > > DER encoding > > Internet application ..or.. application service ..or.. ? > > service provider > > subjectAltName (this term is used in section 1.3 but isn't itself > defined > until seciton 2.2) Added to the terminology section (along with several other terms). > * I think we need to review the terms/phrases we use to reference cert > components and aspects thereof. I think we're being inconsistent and at > times ambiguous (need to do careful review). unfortunately other specs > we depend on use non-congruent terminology it seems. > > E.g. in just sections 2.2 and 3 we use these various terms/phrases wrt > "subjectAltName"... > > subjectAltName extension > > subjectAltName extension types > > subjectAltNames > > subjectAltName entry > > SubjectAltName field > > subjectAltName identifier > > subjectAltName identifier types > > subjectAltName identifier of type > > [the GeneralName structure in] the subjectAltName > > > ..and then including the rest of the spec we also use (in addition to > the above).. > > application-specific subjectAltName extensions > > subjectAltName extension of type > > subjectAltName extensions of type > > > Obviously various of the above terms/phrases are redundant and we ought > to clean this up. Fixed, per my previous message. > --- > end I hope we're nearing the end so that we can request a Last Call soon (several specs now have dependencies on this I-D, including one that's already been approved by the IESG and one that will soon go into IETF Last Call). Peter -- Peter Saint-Andre https://stpeter.im/ From stpeter@stpeter.im Mon Jul 12 10:22:50 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 1A7463A6982 for ; Mon, 12 Jul 2010 10:22:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.832 X-Spam-Level: X-Spam-Status: No, score=-2.832 tagged_above=-999 required=5 tests=[AWL=-0.233, 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 s3aoLWKSGXuB for ; Mon, 12 Jul 2010 10:22:48 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 33A9D3A6407 for ; Mon, 12 Jul 2010 10:22:48 -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 8B76840E44 for ; Mon, 12 Jul 2010 11:22:55 -0600 (MDT) Message-ID: <4C3B4F6E.80903@stpeter.im> Date: Mon, 12 Jul 2010 11:22:54 -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: <201006301746.o5UHkIsE019133@fs4113.wdf.sap.corp> <4C2B843A.5010206@stpeter.im> <4C305B93.9090001@velox.ch> <201007061435.29786.ludwig.nussel@suse.de> <4C335CE5.1090608@edelweb.fr> <4C3421B3.3070404@velox.ch> In-Reply-To: <4C3421B3.3070404@velox.ch> X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [certid] Need to define "most specific RDN" 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, 12 Jul 2010 17:22:50 -0000 On 7/7/10 12:41 AM, Kaspar Brand wrote: > On 06.07.2010 18:42, Peter Sylvester wrote: >> X.500 defines a tree structure, the nodes are relative names put >> into a hierarchie represented by a DN. a prefix of the elements in >> the sequence defines thus a "subtree", and the relative name of a leaf >> is the rightmost element, In a tree the most specific element a leaf >> and moving backwards defined less specific. >> >> There is no need at all to talk about binary encoding, or DER or >> whatever. A DN is a sequence of relative names forming a tree >> structure when interpreted in the X.500 context. This is thus >> one clear interpretation of 'most specific' (for a RDN). > > I don't think that this is the issue here - it's the wording in RFC 2818 > which is the source of all this... well, I'd say, mess: > > 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. > > Matching is performed using the matching rules specified by > [RFC2459]. If more than one identity of a given type is present in > the certificate (e.g., more than one dNSName name, a match in any one > of the set is considered acceptable.) > > Reading "(most specific) Common Name field" as "Common Name in the most > specific RDN" is one interpretation, but I'm not sure if it's the only > one. And given the attention this issue received on the list so far, it > also seems somewhat ironic that this "requirement" is only appearing in > parentheses in an RFC which happens to be informational only, BTW... Is there a good security reason for this "requirement"? I don't see one. >> Anyway, since there is no good reason not to put a subjectAltName, >> I do not think that one shouls say anything more than >> "If you use a Common Name other than in the most simple case one >> may run a risk not to be interpreted correctly." > > A BCP document should say more that just state how implementations > currently behave, I think [1]. For sure. > Leaving that "most specific", peculiar requirement from RFC 2818 aside, > I don't believe that there are really strong arguments against treating > multiple CNs in the subject different from a subjectAltName extension > with multiple dNSName entries - why not consider "a match in any one of > the set[s]" acceptable...? [2] That seems eminently sensible to me. (Whether any given CA would issue such a certificate is a matter of CA policy...) > Clarifying/fixing that blurry "(most specific)" statement from RFC 2818 > would be highly desirable for the new BCP, IMO. If by this we can get > away with a term whose meaning isn't intuitively clear (compare this > e.g. to "left-most DNS label"), then I would definitely consider that a > plus. Would removing all mention of "(most specific)" qualify as clarification? > Kaspar > > > [1] From RFC 2026: a BCP document > [...] is a vehicle by which the IETF > community can define and ratify the community's best current thinking > on a statement of principle or on what is believed to be the best way > to perform some operations or IETF process function." > > [2] I'm aware of Nelson's message at > http://www.ietf.org/mail-archive/web/certid/current/msg00115.html, but > am wondering to how many CAs the statement about unvetted CNs really > applies. In my sample from 2009, the multi-CN certs (211 out of ~90,000) > are basically limited to one of the so-called "commercial CAs", and I'm > pretty sure that this CA does (/claims to) vet all CNs... what they > actually do is mirror the entries from the subjectAltName extension in > the subject DN. Yes, I think that's what is happening in the example cited. Peter -- Peter Saint-Andre https://stpeter.im/ From stpeter@stpeter.im Mon Jul 12 17:27:03 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 5F3A63A6953 for ; Mon, 12 Jul 2010 17:27:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=0.450, 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 uvzT-HKkUpNH for ; Mon, 12 Jul 2010 17:26:56 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 51EE53A67B3 for ; Mon, 12 Jul 2010 17:26:56 -0700 (PDT) Received: from squire.local (dsl-228-115.dynamic-dsl.frii.net [216.17.228.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 6433740E44 for ; Mon, 12 Jul 2010 18:27:03 -0600 (MDT) Message-ID: <4C3BB2C5.9030106@stpeter.im> Date: Mon, 12 Jul 2010 18:26:45 -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: IETF cert-based identity X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [certid] updated CertID spec 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, 13 Jul 2010 00:27:03 -0000 Jeff and I have been working to incorporate all feedback provided on this list. The result is version -08 of the I-D: http://tools.ietf.org/html/draft-saintandre-tls-server-id-check-08 The diff from -07 is here: http://tools.ietf.org/rfcdiff?url2=draft-saintandre-tls-server-id-check-08.txt Also, we will make a brief presentation about this spec during the SAAG session at IETF 78 in Maastricht. We welcome your feedback on this list or at the IETF meeting so that we can prepare this I-D for an IETF Last Call as expeditiously as possible. Thanks! Peter -- Peter Saint-Andre https://stpeter.im/ From paul.hoffman@vpnc.org Mon Jul 12 18:34:25 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 8C06D3A69D6 for ; Mon, 12 Jul 2010 18:34:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.461 X-Spam-Level: X-Spam-Status: No, score=0.461 tagged_above=-999 required=5 tests=[AWL=-0.093, BAYES_50=0.001, HELO_MISMATCH_COM=0.553] 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 KXPQYH7jnCMI for ; Mon, 12 Jul 2010 18:34:24 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id D07753A68AE for ; Mon, 12 Jul 2010 18:34:24 -0700 (PDT) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o6D1YVDD094248 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 12 Jul 2010 18:34:32 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <4C3BB2C5.9030106@stpeter.im> References: <4C3BB2C5.9030106@stpeter.im> Date: Mon, 12 Jul 2010 18:34:29 -0700 To: certid@ietf.org From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: [certid] Sorting the reference identifiers 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, 13 Jul 2010 01:34:25 -0000 Thank you for the -08 update; it looks very good. It clears up a bunch of the comments I was about to make. :-) I still have one leftover question. The middle of Section 4.2 says: The client then orders the list in accordance with the following rules: Then, in 4.3, it checks each reference in this ordered list until it (hopefully) finds a match. Given that it is going to do an exhaustive search, what is the purpose of ordering? --Paul Hoffman, Director --VPN Consortium From ietf-certid@velox.ch Mon Jul 12 22:09: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 C60D63A67E1 for ; Mon, 12 Jul 2010 22:09:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.653 X-Spam-Level: X-Spam-Status: No, score=-0.653 tagged_above=-999 required=5 tests=[AWL=0.654, BAYES_00=-2.599, MISSING_HEADERS=1.292] 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 lpfVoMDaDWH3 for ; Mon, 12 Jul 2010 22:09:45 -0700 (PDT) Received: from appendix.velox.ch (appendix.velox.ch [62.75.148.60]) by core3.amsl.com (Postfix) with ESMTP id D9C0C3A67C0 for ; Mon, 12 Jul 2010 22:09:44 -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 o6D59pYO005455 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 13 Jul 2010 07:09:52 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=velox.ch; s=appendix-177f; t=1278997792; bh=84ehyrh3DQWI3+4moQYStbIaWF16RlVwPMekQ7I0gr4=; h=Message-ID:Date:From:MIME-Version:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=MPyCrSKZ/p8wCXfe56sJYxg/eJwgYyWZGTsk9rSQe/KBGBrdn9zrvizg5hMn7OgLp nPN4qENFPj8SpKFppWfxQi86MlN/pnpiG1WWYi1tevimoBVW7UUp8Dpyt3z4xd3NKi 7H9uZh6Kf4QzeMf4jHU4Van69Q/u1Xwc3g4xjE1qFj0d3CeAbghOzhOIp+WZ3BpkqD 6aczidXnHLFC+vh4pC9kWY5kJ1vKhmJI7lT5CSiiVg5dxZZK5OyRAhHGVewIHdiRPd YYNAunxQDqbhx5B7Dd/EYR2AefPAFyxHEWzf9OUJ3JU+J/QG6Q2iTDxh7H63/L6nrX KMIb4dkTVancg== Message-ID: <4C3BF51E.4030802@velox.ch> DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=velox.ch; s=cortex-8a58; t=1278997790; bh=84ehyrh3DQWI3+4moQYStbIaWF16RlVwPMekQ7I0gr4=; h=Date:From:MIME-Version:CC:Subject:References:In-Reply-To: Content-Type:Content-Transfer-Encoding; b=M2xEUJ1l5QvAcnSpbsjEhgxIYkVUlQOcmk4z5vqHQ5Wx1oPAdKjh4kbuoONsHClH3 vhWjxtrJzhJGyx2xM/jkDhU7p6zFZT1GDrlhb/okm14nUsVoACXKvmQmFnWRDDhu9C aWuE8P8Ao4reNsQL23NWRHT+c1o/qakP9VpiZvyV5NbJ3VWTtDyUuN3xkErSTLDoqX lAE4GTekpJppHU2Onb9/q2b27vZ6ng1b42fRqP4oXClnS7/V9Yn/yEsoOIm2TfZdxQ Hi0AQZ0Nv6u+xFGq+FyUDWsxeUEJx0L8KOIlkl9/9ceewItsHlojjZ93pEsV4lCKD8 YSYcU87y3W9cQ== Date: Tue, 13 Jul 2010 07:09:50 +0200 From: Kaspar Brand User-Agent: Thunderbird/3.x MIME-Version: 1.0 CC: certid@ietf.org References: <201006301746.o5UHkIsE019133@fs4113.wdf.sap.corp> <4C2B843A.5010206@stpeter.im> <4C305B93.9090001@velox.ch> <201007061435.29786.ludwig.nussel@suse.de> <4C335CE5.1090608@edelweb.fr> <4C3421B3.3070404@velox.ch> <4C3B4F6E.80903@stpeter.im> In-Reply-To: <4C3B4F6E.80903@stpeter.im> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [certid] Need to define "most specific RDN" 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, 13 Jul 2010 05:09:47 -0000 On 12.07.2010 19:22, Peter Saint-Andre wrote: > On 7/7/10 12:41 AM, Kaspar Brand wrote: >> Clarifying/fixing that blurry "(most specific)" statement from RFC 2818 >> would be highly desirable for the new BCP, IMO. If by this we can get >> away with a term whose meaning isn't intuitively clear (compare this >> e.g. to "left-most DNS label"), then I would definitely consider that a >> plus. > > Would removing all mention of "(most specific)" qualify as clarification? -08 looks good to me, generally speaking, but in addition to the implementation note at the end of 2.2 I would add some wording to 4.4.4 which states that a) if multiple CN-IDs are found in the subject, all of them should be checked and b) this deliberately allows broader matching than the one originally "specified" in [HTTP-TLS] and [GIST]. (Finally, let me add that browsers such as MSIE, Opera or Safari already implement this kind of multi-CN checking - if there is no subjectAltName extension, they will go through all CNs and look for a match [1]). Kaspar [1] E.g., cf. this discussion from 2004 on apple-cdsa: http://lists.apple.com/archives/apple-cdsa/2004/Apr/msg00012.html From paul.hoffman@vpnc.org Tue Jul 13 09:32:01 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 3225B3A6B2E for ; Tue, 13 Jul 2010 09:32:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.097 X-Spam-Level: X-Spam-Status: No, score=0.097 tagged_above=-999 required=5 tests=[AWL=0.284, BAYES_20=-0.74, HELO_MISMATCH_COM=0.553] 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 5zWA-VbqVvxo for ; Tue, 13 Jul 2010 09:32:00 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id D79303A6B2C for ; Tue, 13 Jul 2010 09:31:59 -0700 (PDT) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o6DGW7so017153 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 Jul 2010 09:32:08 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <4C3BF51E.4030802@velox.ch> References: <201006301746.o5UHkIsE019133@fs4113.wdf.sap.corp> <4C2B843A.5010206@stpeter.im> <4C305B93.9090001@velox.ch> <201007061435.29786.ludwig.nussel@suse.de> <4C335CE5.1090608@edelweb.fr> <4C3421B3.3070404@velox.ch> <4C3B4F6E.80903@stpeter.im> <4C3BF51E.4030802@velox.ch> Date: Tue, 13 Jul 2010 09:32:06 -0700 To: Kaspar Brand From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: certid@ietf.org Subject: Re: [certid] Need to define "most specific RDN" 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, 13 Jul 2010 16:32:01 -0000 At 7:09 AM +0200 7/13/10, Kaspar Brand wrote: >On 12.07.2010 19:22, Peter Saint-Andre wrote: >> On 7/7/10 12:41 AM, Kaspar Brand wrote: >>> Clarifying/fixing that blurry "(most specific)" statement from RFC 2818 >>> would be highly desirable for the new BCP, IMO. If by this we can get >>> away with a term whose meaning isn't intuitively clear (compare this >>> e.g. to "left-most DNS label"), then I would definitely consider that a >>> plus. >> >> Would removing all mention of "(most specific)" qualify as clarification? > >-08 looks good to me, generally speaking, but in addition to the >implementation note at the end of 2.2 I would add some wording to 4.4.4 >which states that a) if multiple CN-IDs are found in the subject, all of >them should be checked Wait, wait. The spec says in a few places that there must only be a single CN. If you add that (which was taken out of -08), you have to change all of them. I propose that we stay with the current MUST for a single CN. > and b) this deliberately allows broader matching >than the one originally "specified" in [HTTP-TLS] and [GIST]. Yes, saying that would be good. >(Finally, let me add that browsers such as MSIE, Opera or Safari already >implement this kind of multi-CN checking - if there is no subjectAltName >extension, they will go through all CNs and look for a match [1]). That doesn't make it a best current practice. --Paul Hoffman, Director --VPN Consortium From ietf-certid@velox.ch Tue Jul 13 11:24: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 589DF3A6B52 for ; Tue, 13 Jul 2010 11:24:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.463 X-Spam-Level: X-Spam-Status: No, score=-1.463 tagged_above=-999 required=5 tests=[AWL=1.137, 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 T3AC+mEBAn6k for ; Tue, 13 Jul 2010 11:24:32 -0700 (PDT) Received: from appendix.velox.ch (appendix.velox.ch [62.75.148.60]) by core3.amsl.com (Postfix) with ESMTP id 0748E3A6B29 for ; Tue, 13 Jul 2010 11:24:31 -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 o6DIOabg022312 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 13 Jul 2010 20:24:40 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=velox.ch; s=appendix-177f; t=1279045480; bh=zKDRRYDdl/apvB4v4LAnYCHUlVHzGTctn2JtlGIaffA=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=PCeRVDWIyVT1zDfKmLvtdXjWgI8NsydZD5NGUBsYkRTpi8D4bDXElFB+VGaStOKzk ja5ghSGgZoYP+I6ZnNq0XULRLQBnNFXYoh8Ri+BJ/b9J7mlcT9fUUW0Xev2nKsRWlA DLTImA5tS63ESYwdpQ6Dht6gsrjIG3qS5d3/MBucp330m4ajK6qgQXypx6uaR6nvWk ffDJDLuZ2QAzCTEmqPt9UnKz8VxOCDi+l87laixg9M/fL+TInUqzp3hS13y5N94llO 8lkOXbRdkaRnbWprug03ifMNty7VfHgjurBHm2D+c3NYI+Yyg/++x43RJAwu3VpuCU lXCX2RTz9TiRw== Message-ID: <4C3CAF64.3050303@velox.ch> DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=velox.ch; s=cortex-8a58; t=1279045476; bh=zKDRRYDdl/apvB4v4LAnYCHUlVHzGTctn2JtlGIaffA=; h=Date:From:MIME-Version:To:Subject:References:In-Reply-To: Content-Type:Content-Transfer-Encoding; b=BdiQnJRaq2EPigSPUxEeP2wmemYT3hj/a64KhzWoNBlgO/xknlh2Dg7MBze3Rt6Pl 3z8bSHurQUQ+FjyPbp/ZSzb4GrJyitGFXsawBp1RSJQKQ4tHpYATlQ/IqMfVkNm1cz NJ3m6635NaNKanJIcqw3wkX1JdceyHUn+qTFBKKd7PaTcwhhDCV1XXCmPllwdXPMRN D5WrRYr2Xs6HgvrO1LVJQJ9G1KY+MUVjWudBgohWnQknCZ18vgVe7wN1V7XIaBnE0i xldPvTfvHwCG/Ime7JJUQSP7OFMpLkIgwBgBvqJMgXkBi6oFQ4WteaFRJY+qqlaMdJ yOeoHMr2/DANw== Date: Tue, 13 Jul 2010 20:24:36 +0200 From: Kaspar Brand User-Agent: Thunderbird/3.x MIME-Version: 1.0 To: certid@ietf.org References: <201006301746.o5UHkIsE019133@fs4113.wdf.sap.corp> <4C2B843A.5010206@stpeter.im> <4C305B93.9090001@velox.ch> <201007061435.29786.ludwig.nussel@suse.de> <4C335CE5.1090608@edelweb.fr> <4C3421B3.3070404@velox.ch> <4C3B4F6E.80903@stpeter.im> <4C3BF51E.4030802@velox.ch> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [certid] Need to define "most specific RDN" 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, 13 Jul 2010 18:24:36 -0000 On 13.07.2010 18:32, Paul Hoffman wrote: > At 7:09 AM +0200 7/13/10, Kaspar Brand wrote: >> -08 looks good to me, generally speaking, but in addition to the >> implementation note at the end of 2.2 I would add some wording to >> 4.4.4 which states that a) if multiple CN-IDs are found in the >> subject, all of them should be checked > > Wait, wait. The spec says in a few places that there must only be a > single CN. If you add that (which was taken out of -08), you have to > change all of them. I'm not sure I'm following you. Add what "which was taken out of -08"? Section 3 currently says: If a CN-ID is included, the certificate's subject field SHOULD NOT contain more than one CN-ID, and MUST NOT contain RDNs which consist of multiple Common Name attributes. and CN-ID is defined as * CN-ID = a Relative Distinguished Name (RDN) in the certificate subject that contains one and only one attribute-type-and-value pair of type Common Name (CN); see [PKIX] and also [LDAP-SCHEMA] What's underspecified in 4.4.4 is how CN checking should be done if multiple CN-IDs are present, but that's the only place where it needs to be covered, I think. > I propose that we stay with the current MUST for a single CN. But this wouldn't really address the issue of how to handle a certificate with multiple CNs in the subject... and they do occur in the wild, so they shouldn't simply be ignored in this document - let's use the opportunity to specify this explicitly. >> (Finally, let me add that browsers such as MSIE, Opera or Safari >> already implement this kind of multi-CN checking - if there is no >> subjectAltName extension, they will go through all CNs and look for >> a match [1]). > > That doesn't make it a best current practice. Not in the literal sense, because currently there's no real consensus on the meaning of the "(most specific) Common Name field" statement from RFC 2818, so implementations differ in their behavior right now. I would at least consider it "best future practice", however, given that you would no longer have to argue about most specific vs. least specific etc. Kaspar From Jeff.Hodges@KingsMountain.com Tue Jul 13 13:49: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 DB8BF3A67D7 for ; Tue, 13 Jul 2010 13:49:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.077 X-Spam-Level: X-Spam-Status: No, score=-1.077 tagged_above=-999 required=5 tests=[AWL=1.188, BAYES_00=-2.599, 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 b4sXbaMEtMcP for ; Tue, 13 Jul 2010 13:49:11 -0700 (PDT) Received: from cpoproxy2-pub.bluehost.com (cpoproxy2-pub.bluehost.com [67.222.39.38]) by core3.amsl.com (Postfix) with SMTP id F00F73A6831 for ; Tue, 13 Jul 2010 13:49:10 -0700 (PDT) Received: (qmail 11624 invoked by uid 0); 13 Jul 2010 20:49:20 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by cpoproxy2.bluehost.com with SMTP; 13 Jul 2010 20:49:20 -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=5vhL1SdDgXmABrV3tGm2Et42yNu9VoMcu5ZDo17FQxmKVmUirBysfvbDxHmnSLnKULIdM57vgbAXSWeW+QkcHec5QarrNFWu1dcw4k05qGfpBzIjcE7I7y38Vq6yzK05; Received: from c-24-4-122-173.hsd1.ca.comcast.net ([24.4.122.173] helo=[192.168.11.10]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1OYmPn-0006Dh-LB for certid@ietf.org; Tue, 13 Jul 2010 14:49:19 -0600 Message-ID: <4C3CD14D.2010705@KingsMountain.com> Date: Tue, 13 Jul 2010 13:49:17 -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 24.4.122.173 authed with jeff.hodges+kingsmountain.com} Subject: [certid] wrt -tls-server-id-check "profileability" 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, 13 Jul 2010 20:49:12 -0000 StPeter indicates that -tls-server-id-check is "profileable". E.g. draft-ietf-xmpp-3920bis explicitly profiles -tls-server-id-check in its section "13.7.1.2. Server Certificates".. ..although we don't make it explicitly clear (it seems to me/peter) in -tls-server-id-check that it is indeed profileable, nor how to go about profiling it. So is it the case that at this time we're regarding _all_ the stuff in section 1.2.2 to be the degrees of profileability freedom? =JeffH From nelson@bolyard.me Wed Jul 14 08:47: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 DFD3B3A6B7F for ; Wed, 14 Jul 2010 08:47:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.67 X-Spam-Level: X-Spam-Status: No, score=-1.67 tagged_above=-999 required=5 tests=[AWL=-0.930, 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 xuh-jPTAtAOH for ; Wed, 14 Jul 2010 08:47:37 -0700 (PDT) Received: from smtpauth18.prod.mesa1.secureserver.net (smtpauth18.prod.mesa1.secureserver.net [64.202.165.31]) by core3.amsl.com (Postfix) with SMTP id 511493A6B73 for ; Wed, 14 Jul 2010 08:47:34 -0700 (PDT) Received: (qmail 29462 invoked from network); 14 Jul 2010 15:47:41 -0000 Received: from unknown (24.5.142.42) by smtpauth18.prod.mesa1.secureserver.net (64.202.165.31) with ESMTP; 14 Jul 2010 15:47:41 -0000 Message-ID: <4C3DDC18.4020808@bolyard.me> Date: Wed, 14 Jul 2010 08:47:36 -0700 From: Nelson B Bolyard Organization: Network Security Services User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b1pre) Gecko/20081004 Firefox/3.5 Firefox/3.5 MIME-Version: 1.0 To: certid@ietf.org References: <201006301746.o5UHkIsE019133@fs4113.wdf.sap.corp> <4C2B843A.5010206@stpeter.im> <4C305B93.9090001@velox.ch> <201007061435.29786.ludwig.nussel@suse.de> <4C335CE5.1090608@edelweb.fr> <4C3421B3.3070404@velox.ch> <4C3B4F6E.80903@stpeter.im> In-Reply-To: <4C3B4F6E.80903@stpeter.im> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [certid] Need to define "most specific RDN" 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, 14 Jul 2010 15:47:42 -0000 On 2010-07-12 10:22 PDT, Peter Saint-Andre wrote: > On 7/7/10 12:41 AM, Kaspar Brand wrote: >> On 06.07.2010 18:42, Peter Sylvester wrote: >>> X.500 defines a tree structure, the nodes are relative names put >>> into a hierarchie represented by a DN. a prefix of the elements in >>> the sequence defines thus a "subtree", and the relative name of a leaf >>> is the rightmost element, In a tree the most specific element a leaf >>> and moving backwards defined less specific. >>> >>> There is no need at all to talk about binary encoding, or DER or >>> whatever. A DN is a sequence of relative names forming a tree >>> structure when interpreted in the X.500 context. This is thus >>> one clear interpretation of 'most specific' (for a RDN). >> I don't think that this is the issue here - it's the wording in RFC 2818 >> which is the source of all this... well, I'd say, mess: >> >> 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. >> >> Matching is performed using the matching rules specified by >> [RFC2459]. If more than one identity of a given type is present in >> the certificate (e.g., more than one dNSName name, a match in any one >> of the set is considered acceptable.) >> >> Reading "(most specific) Common Name field" as "Common Name in the most >> specific RDN" is one interpretation, but I'm not sure if it's the only >> one. And given the attention this issue received on the list so far, it >> also seems somewhat ironic that this "requirement" is only appearing in >> parentheses in an RFC which happens to be informational only, BTW... > > Is there a good security reason for this "requirement"? I don't see one. > >>> Anyway, since there is no good reason not to put a subjectAltName, >>> I do not think that one shouls say anything more than >>> "If you use a Common Name other than in the most simple case one >>> may run a risk not to be interpreted correctly." >> A BCP document should say more that just state how implementations >> currently behave, I think [1]. > > For sure. > >> Leaving that "most specific", peculiar requirement from RFC 2818 aside, >> I don't believe that there are really strong arguments against treating >> multiple CNs in the subject different from a subjectAltName extension >> with multiple dNSName entries - why not consider "a match in any one of >> the set[s]" acceptable...? [2] > > That seems eminently sensible to me. (Whether any given CA would issue > such a certificate is a matter of CA policy...) > >> Clarifying/fixing that blurry "(most specific)" statement from RFC 2818 >> would be highly desirable for the new BCP, IMO. If by this we can get >> away with a term whose meaning isn't intuitively clear (compare this >> e.g. to "left-most DNS label"), then I would definitely consider that a >> plus. > > Would removing all mention of "(most specific)" qualify as clarification? Gaa! Let's not open Pandora's box wider!! One of the big weaknesses of PKI right now is the lack of effective use of name constraints. CAs do not constrain the names that their subordinate CAs may issue. And one of the big reasons for that is that name constraints are not defined to apply to DNS names in Subject CNs, so they're ineffective. Trying to apply DNS name constraints to subject CNs is a can of worms, because subject CNs may legitimately contain things that are not DNS names at all. It's not correct to declare a cert chain invalid because the EE cert contains CN="Peter Saint-Andre" and also CN="www.stpeter.im" but the issuer CA is constrained to "*.stpeter.im". There's no test that 100% accurately answers the question "Is this string a DNS name or not?", and so it is not generally possible to answer the question "Should this CN be subjected to a DNS name constraint or not?". SANs solve this whole problem. They have a component that may ONLY contain DNS names, and therefore is easily constrained. DNS name constraints would be effective if certs ONLY put DNS names into SANs. But putting DNS names into SANs effectively bypasses name constraints (at least, in implementations I tested last year). IMO, we should be attempting to drive a stake in the heart of DNS names in subject CNs, and moving all CAs to use SANs exclusively for DNS names. Let's close Pandora's box, not open it wider. From ietf-certid@velox.ch Wed Jul 14 22:07: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 CB79E3A66B4 for ; Wed, 14 Jul 2010 22:07:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.76 X-Spam-Level: X-Spam-Status: No, score=-0.76 tagged_above=-999 required=5 tests=[AWL=-0.020, 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 23g6pdtyGF2c for ; Wed, 14 Jul 2010 22:07:32 -0700 (PDT) Received: from appendix.velox.ch (appendix.velox.ch [62.75.148.60]) by core3.amsl.com (Postfix) with ESMTP id 797A53A69F1 for ; Wed, 14 Jul 2010 22:07:30 -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 o6F57d11023973 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 15 Jul 2010 07:07:40 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=velox.ch; s=appendix-177f; t=1279170460; bh=K/oGKZN5xAPK5fMqOZDMVEWPxcNlGC5PgzNX1O1cjkY=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=QwmmjV7I3hL2Y761JOeONPKlx2hKTMDXZB/X6sAOTcUZKgvqhcNV1pE8tJTSXKeHe yVEjpvxguEAuQ2t/Dt92pKOjY79LoLDHT/fHGphQtIO+1l4rZXmkpZNiM/wwv1xWUA ZH9Q8PW6AUdW/gqCfFApbdxyQOOg5HMXBH11Zm2OJq4Kpfa1oRI8Z8Z+zlTNT3gSDF C2L2Q07kApmw4NmiQxhyoEUHOL5rqTXtYw46LwsXUiuplBt6k/jN3zbG+H/KgPw9rR w0YreV3fri1uZ9+kDmhIxXe81CzY4Pd0C7p+GfjTxpPaYVZcp37IovDFSy8/zsxCNB CIgiKBNgHH8Hw== Message-ID: <4C3E979B.4050401@velox.ch> DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=velox.ch; s=cortex-8a58; t=1279170458; bh=K/oGKZN5xAPK5fMqOZDMVEWPxcNlGC5PgzNX1O1cjkY=; h=Date:From:MIME-Version:To:Subject:References:In-Reply-To: Content-Type:Content-Transfer-Encoding; b=kSl0gcx48+i8tPdSWXWvFAVnL+BFYraeVbqhWKghBtKYqf5CtYXRhFbsTkJZt9ZuS QpiuNZl0+Ug5fLNtUXa7M4+4JjtPq1xyh3zGGJIG460Hof/2RB45fjtExvVn/wqgkU OjUREo4xuZI2ErkO2znSoiMIYCfUZVVIZKg9wIK6UIfZ8Vkxwc9FOCYk5R1viQC3pz XdJnj98bJ/nIsjMpuY0EEUFyYDEI07hqjX+t3FHgGLGsWUTgqD1IOmfRh1VEyvj0/y yByo1JWtYGy6CTl4CDFvbjldmfzEF0oB+IqSH4bSQ0c8RT30rFtesT9obKWgCHx5dw qU9+5002JUw8Q== Date: Thu, 15 Jul 2010 07:07:39 +0200 From: Kaspar Brand User-Agent: Thunderbird/3.x MIME-Version: 1.0 To: certid@ietf.org References: <201006301746.o5UHkIsE019133@fs4113.wdf.sap.corp> <4C2B843A.5010206@stpeter.im> <4C305B93.9090001@velox.ch> <201007061435.29786.ludwig.nussel@suse.de> <4C335CE5.1090608@edelweb.fr> <4C3421B3.3070404@velox.ch> <4C3B4F6E.80903@stpeter.im> <4C3DDC18.4020808@bolyard.me> In-Reply-To: <4C3DDC18.4020808@bolyard.me> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [certid] Need to define "most specific RDN" 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, 15 Jul 2010 05:07:42 -0000 On 14.07.2010 17:47, Nelson B Bolyard wrote: > Trying to apply DNS name constraints to subject CNs is a can of worms, > because subject CNs may legitimately contain things that are not DNS names > at all. It's not correct to declare a cert chain invalid because the EE > cert contains CN="Peter Saint-Andre" and also CN="www.stpeter.im" but the > issuer CA is constrained to "*.stpeter.im". There's no test that 100% > accurately answers the question "Is this string a DNS name or not?", and > so it is not generally possible to answer the question "Should this CN > be subjected to a DNS name constraint or not?". > > SANs solve this whole problem. They have a component that may ONLY contain > DNS names, and therefore is easily constrained. DNS name constraints would > be effective if certs ONLY put DNS names into SANs. That's an argument for completely banning CN-IDs, in the first place. But I fail to see how it is relevant for the decision whether to only check the "(most specific) Common Name field" or all of the CNs. > But putting DNS names > into SANs effectively bypasses name constraints (at least, in > implementations I tested last year). Should read "... into CNs", I guess? In any case, if you disregard CNs in the subject for name matching as soon as there is a subjectAltName extension with at least one dNSName (as draft-saintandre-tls-server-id-check-08 does), then it's becoming a non-issue. > IMO, we should be attempting to drive a stake in the heart of DNS names in > subject CNs, and moving all CAs to use SANs exclusively for DNS names. -08 already does this in several places: The certificate SHOULD NOT represent the server's fully-qualified DNS domain name in a CN-ID, even though many deployed clients still check for this legacy identifier configuration within certificate subjectName. [...] Notwithstanding any of the foregoing rules, reference identifiers of type CN-ID (if included) MUST always be the lowest-priority reference identifiers in the list. [...] Security 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 entry types supported by the client. I'm doubtful if adding a MUST NOT for CN-IDs (vs. a SHOULD NOT) would have a considerable impact on future CA practices. Most of them probably don't want to risk compatibility issues with legacy implementations (which don't recognize the subjectAltName extension). Kaspar From mrex@sap.com Thu Jul 15 08:36:45 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 7659C3A6B2B for ; Thu, 15 Jul 2010 08:36:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.107 X-Spam-Level: X-Spam-Status: No, score=-9.107 tagged_above=-999 required=5 tests=[AWL=0.542, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_62=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 PRT1stZhtupm for ; Thu, 15 Jul 2010 08:36:42 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 76C443A6B49 for ; Thu, 15 Jul 2010 08:36:34 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id o6FFah8s009342 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 15 Jul 2010 17:36:44 +0200 (MEST) From: Martin Rex Message-Id: <201007151536.o6FFahVc005437@fs4113.wdf.sap.corp> To: ietf-certid@velox.ch (Kaspar Brand) Date: Thu, 15 Jul 2010 17:36:43 +0200 (MEST) In-Reply-To: <4C3E979B.4050401@velox.ch> from "Kaspar Brand" at Jul 15, 10 07:07:39 am 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] Need to define "most specific RDN" 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: Thu, 15 Jul 2010 15:36:45 -0000 Kaspar Brand wrote: > > On 14.07.2010 17:47, Nelson B Bolyard wrote: > > > > SANs solve this whole problem. They have a component that may ONLY contain > > DNS names, and therefore is easily constrained. DNS name constraints would > > be effective if certs ONLY put DNS names into SANs. > > That's an argument for completely banning CN-IDs, in the first place. > But I fail to see how it is relevant for the decision whether to only > check the "(most specific) Common Name field" or all of the CNs. In the PKIX specs implementing name constraints for DNames is a MUST, while implementation of DNSName SANs officially "RECOMMENDED" and in reality probably a MAY. > > > But putting DNS names > > into SANs effectively bypasses name constraints (at least, in > > implementations I tested last year). > > Should read "... into CNs", I guess? AFAIK, Name constraints conceptually are supposed to work at the certificate path validation level. So a name constraint imposed by a rootCA for an intermediate CA works for exactly that particular type of name. If applications check for acceptable names in certs by comparing with different types of names (like DNSName SAN and CN-ID), then a name constraint on only one of them is obviously ineffective from preventing the intermediate CA to bypass the name constraint. > > In any case, if you disregard CNs > in the subject for name matching as soon as there is a subjectAltName > extension with at least one dNSName (as > draft-saintandre-tls-server-id-check-08 does), then it's becoming a > non-issue. I don't think this is an appropriate characterization of the issues at hand. There are a number of parties involved, each with very different objectives. Name constraints is tool for a multi-CA hierarchy that a CA higher up the hierarchy can use to impose limits to the authority of CAs closer to or issuing the EE certs. name constraints are not in the interest of the server, not in the interest of the client and not necessarily in the interest of the issuing CA (the presencs of name constraints is evidence that it is not in the interest of the issuing CA -- but instead in the interest of the higher up CA). The inclusion of DNSName SANs or CN-IDs in a Servers EE-Cert might be in the interest of the Server, might be in the interest of the issuing CA or might be a mere technical restriction of the CA's software or the CA's configuration. A Server that intentionally uses an EE-Cert with DNSName SANs has no control over the clients that connect to that server. Whether these clients understand DNSName SANs or only CN-IDs, or whether these clients ignore CN-IDs when DNSName SANs are present or always check both, is also completely outside of the control of the server. The server and the issuing CA might consent to not put a CN-ID into the server's EE-Cert, but that is likely result is a number of clients rejecting the server's cert. > > > IMO, we should be attempting to drive a stake in the heart of DNS names in > > subject CNs, and moving all CAs to use SANs exclusively for DNS names. That decision, and the risk management for the resulting interop problems, should be left to the combined decision of the Server operator and issuing CA to no longer include CN-IDs in EE-Certs on a case-by-case basis. > > -08 already does this in several places: > > The certificate SHOULD NOT represent the server's fully-qualified > DNS domain name in a CN-ID, even though many deployed clients > still check for this legacy identifier configuration within > certificate subjectName. [...] > > Notwithstanding any of the foregoing rules, reference identifiers > of type CN-ID (if included) MUST always be the lowest-priority > reference identifiers in the list. [...] It has been recently asked (I think by Paul Hoffman) why there is an ordering when checking is going to be performed as a linear search, and similarly I'm wondering what "lowest-priority reference identifiers" is supposed to mean here. I assumed the matching was about a Boolean decision, either it matches the servers identity or it doesn't match. "lowest-priority" sounds like a XX% acceptable match instead of a Boolean. > > Security 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 > entry types supported by the client. This MUST NOT is an unnecessary a violation of rfc-2119 section 6, and completely ignorant of the situation that software updates must not break the installed base. It is trivial for the server&CA to make this happen by having the CA issue a Cert without CN-ID. -Martin From alexey.melnikov@isode.com Thu Jul 15 16:23: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 5FE763A6AD6 for ; Thu, 15 Jul 2010 16:23:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.323 X-Spam-Level: X-Spam-Status: No, score=-2.323 tagged_above=-999 required=5 tests=[AWL=0.276, 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 ltMJy20gZDCf for ; Thu, 15 Jul 2010 16:23:45 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 434D73A6982 for ; Thu, 15 Jul 2010 16:23:45 -0700 (PDT) Received: from [172.16.2.135] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Fri, 16 Jul 2010 00:23:55 +0100 Message-ID: <4C3F9878.40201@isode.com> Date: Fri, 16 Jul 2010 00:23:36 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: IETF cert-based identity MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------000405080309090000090704" Subject: [certid] [Fwd: Last Call: draft-saintandre-tls-server-id-check (Representation and Verification of Domain-Based Application Service Identity in Certificates Used with Transport Layer Security) to Proposed Standard] 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, 15 Jul 2010 23:23:46 -0000 This is a multi-part message in MIME format. --------------000405080309090000090704 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit I've decided to initiated IETF LC on the document, because I think the document is nearly done and outstanding issues can be addressed after IETF LC. So please review, talk to me and Peter/Jeff about the document during the Maastricht IETF, etc. Regards, Alexey --------------000405080309090000090704 Content-Type: message/rfc822; name="Last Call: draft-saintandre-tls-server-id-check (Representation and Verificationof Domain-Based Application Service Identity in Certificates Used with TransportLayer Security) to Proposed Standard" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="Last Call: draft-saintandre-tls-server-id-check (Representation and Verificationof Domain-Based Application Service Identity in Certificates Used with TransportLayer Security) to Proposed Standard" Return-Path: Received: from rufus.isode.com ([62.3.217.251]) by canine.isode.net (Isode M-Box/14.6a3) with LMTP; Fri, 16 Jul 2010 00:08:46 +0100 (BST) Received: from mail.ietf.org ([64.170.98.32]) by rufus.isode.com (smtp external) via TCP with ESMTP id for ; Fri, 16 Jul 2010 00:08:46 +0100 X-SPF-Result: PASS rufus.isode.com: domain of ietf.org designates 64.170.98.32 as permitted sender Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B88123A6BB4; Thu, 15 Jul 2010 16:08:23 -0700 (PDT) X-Original-To: ietf-announce@ietf.org Delivered-To: ietf-announce@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 5B1583A6B94; Thu, 15 Jul 2010 16:08:22 -0700 (PDT) X-idtracker: yes To: IETF-Announce From: The IESG Subject: Last Call: draft-saintandre-tls-server-id-check (Representation and Verification of Domain-Based Application Service Identity in Certificates Used with Transport Layer Security) to Proposed Standard Message-Id: <20100715230822.5B1583A6B94@core3.amsl.com> Date: Thu, 15 Jul 2010 16:08:22 -0700 (PDT) X-BeenThere: ietf-announce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: "IETF announcement list. No discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ietf-announce-bounces@ietf.org Errors-To: ietf-announce-bounces@ietf.org The IESG has received a request from an individual submitter to consider the following document: - 'Representation and Verification of Domain-Based Application Service Identity in Certificates Used with Transport Layer Security ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2010-08-12. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-saintandre-tls-server-id-check-08.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=18634&rfc_flag=0 _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce --------------000405080309090000090704-- From nelson@bolyard.me Thu Jul 15 18:04: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 11F8C3A687F for ; Thu, 15 Jul 2010 18:04:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 E00oliaW0oL2 for ; Thu, 15 Jul 2010 18:04:44 -0700 (PDT) Received: from p3plsmtpa01-10.prod.phx3.secureserver.net (p3plsmtpa01-10.prod.phx3.secureserver.net [72.167.82.90]) by core3.amsl.com (Postfix) with SMTP id 940023A6860 for ; Thu, 15 Jul 2010 18:04:44 -0700 (PDT) Received: (qmail 22696 invoked from network); 16 Jul 2010 01:04:54 -0000 Received: from unknown (74.121.22.10) by p3plsmtpa01-10.prod.phx3.secureserver.net (72.167.82.90) with ESMTP; 16 Jul 2010 01:04:54 -0000 Message-ID: <4C3FB02F.3090006@bolyard.me> Date: Thu, 15 Jul 2010 18:04:47 -0700 From: Nelson B Bolyard User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: certid@ietf.org References: <201006301746.o5UHkIsE019133@fs4113.wdf.sap.corp> <4C2B843A.5010206@stpeter.im> <4C305B93.9090001@velox.ch> <201007061435.29786.ludwig.nussel@suse.de> <4C335CE5.1090608@edelweb.fr> <4C3421B3.3070404@velox.ch> <4C3B4F6E.80903@stpeter.im> <4C3DDC18.4020808@bolyard.me> <4C3E979B.4050401@velox.ch> In-Reply-To: <4C3E979B.4050401@velox.ch> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [certid] Need to define "most specific RDN" 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, 16 Jul 2010 01:04:46 -0000 On 2010/07/14 22:07 PDT, Kaspar Brand wrote: > On 14.07.2010 17:47, Nelson B Bolyard wrote: >> Trying to apply DNS name constraints to subject CNs is a can of >> worms, because subject CNs may legitimately contain things that are >> not DNS names at all. It's not correct to declare a cert chain >> invalid because the EE cert contains CN="Peter Saint-Andre" and >> also CN="www.stpeter.im" but the issuer CA is constrained to >> "*.stpeter.im". There's no test that 100% accurately answers the >> question "Is this string a DNS name or not?", and so it is not >> generally possible to answer the question "Should this CN be >> subjected to a DNS name constraint or not?". >> >> SANs solve this whole problem. They have a component that may ONLY >> contain DNS names, and therefore is easily constrained. DNS name >> constraints would be effective if certs ONLY put DNS names into >> SANs. > > That's an argument for completely banning CN-IDs, in the first > place. But I fail to see how it is relevant for the decision whether > to only check the "(most specific) Common Name field" or all of the > CNs. See my argument below. >> But putting DNS names into SANs effectively bypasses name >> constraints (at least, in implementations I tested last year). > > Should read "... into CNs", I guess? Yes, sorry. > In any case, if you disregard CNs in the subject for name matching as > soon as there is a subjectAltName extension with at least one dNSName > (as draft-saintandre-tls-server-id-check-08 does), then it's becoming > a non-issue. Yes, but as I read it, people here are proposing to open the spec to say that multiple CN-IDs are just as acceptable as multiple DNS names in a SAN. Frankly, IMO, that will kill SANs and name constraints too. SANs are having enough trouble getting off the ground. FAR too many people still think that CN-IDs are *THE* standard, and are utterly unaware of SANs. If we raise multiple CN-IDs to a status they did not enjoy with RFC 2818, then there will remain no motivation to use SANs at all, and constraints will die. Today, the ONE motivation to use SANs is to get multiple DNS names into a cert. And that brings with it the hope of constraints. Take away that sole motivation, and constraints die. Sorry, I'm repeating myself. This constraints issue is very important. >> IMO, we should be attempting to drive a stake in the heart of DNS names in >> subject CNs, and moving all CAs to use SANs exclusively for DNS names. > > -08 already does this in several places: > > The certificate SHOULD NOT represent the server's fully-qualified > DNS domain name in a CN-ID, even though many deployed clients > still check for this legacy identifier configuration within > certificate subjectName. [...] > > Notwithstanding any of the foregoing rules, reference identifiers > of type CN-ID (if included) MUST always be the lowest-priority > reference identifiers in the list. [...] > > Security 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 > entry types supported by the client. > > I'm doubtful if adding a MUST NOT for CN-IDs (vs. a SHOULD NOT) would > have a considerable impact on future CA practices. Most of them probably > don't want to risk compatibility issues with legacy implementations > (which don't recognize the subjectAltName extension). Can you name any browser or other important network client made in the last 8 years (since RFC 3280 was published) that does SSL3 and/or TLS but doesn't recognize DNS names in SANs? Best Regards, /Nelson From ietf-certid@velox.ch Thu Jul 15 22:29:29 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 CAEC03A68EC for ; Thu, 15 Jul 2010 22:29:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.686 X-Spam-Level: X-Spam-Status: No, score=-1.686 tagged_above=-999 required=5 tests=[AWL=0.913, 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 FvmdIc22GXlr for ; Thu, 15 Jul 2010 22:29:27 -0700 (PDT) Received: from appendix.velox.ch (appendix.velox.ch [62.75.148.60]) by core3.amsl.com (Postfix) with ESMTP id 891943A68C2 for ; Thu, 15 Jul 2010 22:29:27 -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 o6G5TadG003796 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 16 Jul 2010 07:29:37 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=velox.ch; s=appendix-177f; t=1279258177; bh=4qZ7z13YdueSQoCNp1FU8AZNeDU3scp8mlWzeipuuxo=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=OTgbQMaFX9OUlwsG0iTUvs7PNqBgj2G8FiLCqj4futHr9S90VnEo0jGkbo3PLzXTl e3zud7NciJlz8HTCt5l8Rb8OJcJuWijzx3se+ViPS4z5V65o67X30hmC4cACwEfDWN WS5Uz7VV4pHxczTQjQo8BPIXmxZFyqnzlvd/NN/Fn1aADUd39EUINN4JrezYwuxqFg m2+pMa2HFlHx3GOH26SPkSNHMPSLSjWxbMDNuG3ZovzQX4zkyDYDtf6NQsBWbb9CvY 8vJdD6SNow64YubY532fbvkfIlO5Qg7HYTjgOwVFx3XFHfo1zLw4EMjRJ+GCtO0+i1 E0moqQv75vqlA== Message-ID: <4C3FEE41.5050209@velox.ch> DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=velox.ch; s=cortex-8a58; t=1279258176; bh=4qZ7z13YdueSQoCNp1FU8AZNeDU3scp8mlWzeipuuxo=; h=Date:From:MIME-Version:To:Subject:References:In-Reply-To: Content-Type:Content-Transfer-Encoding; b=pkluuKCPB6EgMVPytsMewaFIT+UJcHSj1JF8HECzDe7f3wJDxxV0i7dS2N3tLYwe0 Sex86qK2xpVLlAj8W/NmToDux4q4tWqs1skXpl4YY3KrqdzLiAHuU2ihTCeaGj3h0b 31dje8DkbEYWrUosJ2YFANQpapxVebPNQ7nIEqPmxlrWQ5GVQ3IFm9uN9JSqExMMyM 0CExDWt1xk8iS7CLe0a+gPwPsjo//4CH/C9fn+BTrh8RfYF/pEx8CX9xEyBl2d3Nm1 sBTJtc6GIrGETs/dkWLmSQ33H66KtyNaUBU+K3Y6Kw7j+ayJcZF2vDKcUAiXdxKzyS SKvjE7oQVvthA== Date: Fri, 16 Jul 2010 07:29:37 +0200 From: Kaspar Brand User-Agent: Thunderbird/3.x MIME-Version: 1.0 To: certid@ietf.org References: <201006301746.o5UHkIsE019133@fs4113.wdf.sap.corp> <4C2B843A.5010206@stpeter.im> <4C305B93.9090001@velox.ch> <201007061435.29786.ludwig.nussel@suse.de> <4C335CE5.1090608@edelweb.fr> <4C3421B3.3070404@velox.ch> <4C3B4F6E.80903@stpeter.im> <4C3DDC18.4020808@bolyard.me> <4C3E979B.4050401@velox.ch> <4C3FB02F.3090006@bolyard.me> In-Reply-To: <4C3FB02F.3090006@bolyard.me> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [certid] Need to define "most specific RDN" 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, 16 Jul 2010 05:29:30 -0000 On 16.07.2010 03:04, Nelson B Bolyard wrote: > On 2010/07/14 22:07 PDT, Kaspar Brand wrote: >> In any case, if you disregard CNs in the subject for name matching as >> soon as there is a subjectAltName extension with at least one dNSName >> (as draft-saintandre-tls-server-id-check-08 does), then it's becoming >> a non-issue. > > Yes, but as I read it, people here are proposing to open the spec to say > that multiple CN-IDs are just as acceptable as multiple DNS names in a > SAN. Acceptable in the sense that a certificate with multiple CNs and no subjectAltName extension is treated the same as a certificate with multiple dNSName entries in the subjectAltName extension, yes. When it comes to name constraints, this BCP document now says what cert parts an implementation should take into account as potential identifiers, effectively closing a gap which is left between RFC 5280 and RFC 2818. > SANs are having enough trouble getting off the ground. FAR too many > people still think that CN-IDs are *THE* standard, and are utterly > unaware of SANs. If we raise multiple CN-IDs to a status they did not > enjoy with RFC 2818, then there will remain no motivation to use SANs at > all, and constraints will die. I'm not sure if beating people to use SANs by putting fierce requirements into a BCP document ("MUST NOT put server names into CN attributes") is the right way to evangelize them. > Today, the ONE motivation to use SANs is to get multiple DNS names into > a cert. And that brings with it the hope of constraints. Take away > that sole motivation, and constraints die. > > Sorry, I'm repeating myself. This constraints issue is very important. I have a somewhat different view, but it's also getting a bit off-topic for this thread, I think. Just one point to be aware of: name constraints will only take off if *all* relevant TLS toolkits implement them - otherwise trying to constrain intermediate CAs (through an extension which some will just ignore) is pretty pointless. >> I'm doubtful if adding a MUST NOT for CN-IDs (vs. a SHOULD NOT) would >> have a considerable impact on future CA practices. Most of them probably >> don't want to risk compatibility issues with legacy implementations >> (which don't recognize the subjectAltName extension). > > Can you name any browser or other important network client made in the > last 8 years (since RFC 3280 was published) that does SSL3 and/or TLS > but doesn't recognize DNS names in SANs? "important" is a debatable term, but I'm pretty sure that as soon as you leave the browser camp, you'll encounter quite a few... I didn't have to search for a long time, actually: take wget as an example. Kaspar From ludwig.nussel@suse.de Fri Jul 16 01:24:48 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 83A423A6949 for ; Fri, 16 Jul 2010 01:24:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.649 X-Spam-Level: X-Spam-Status: No, score=-103.649 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_DE=0.35, 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 WjVSeesdff+d for ; Fri, 16 Jul 2010 01:24:47 -0700 (PDT) Received: from mx2.suse.de (cantor2.suse.de [195.135.220.15]) by core3.amsl.com (Postfix) with ESMTP id 8B2723A69A9 for ; Fri, 16 Jul 2010 01:24:47 -0700 (PDT) Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.221.2]) by mx2.suse.de (Postfix) with ESMTP id 4FED88655F for ; Fri, 16 Jul 2010 10:24:58 +0200 (CEST) From: Ludwig Nussel To: certid@ietf.org Date: Fri, 16 Jul 2010 10:24:52 +0200 User-Agent: KMail/1.13.3 (Linux/2.6.34-9-desktop; KDE/4.4.3; x86_64; ; ) References: <201006301746.o5UHkIsE019133@fs4113.wdf.sap.corp> <4C3FB02F.3090006@bolyard.me> <4C3FEE41.5050209@velox.ch> In-Reply-To: <4C3FEE41.5050209@velox.ch> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201007161024.53340.ludwig.nussel@suse.de> Subject: Re: [certid] Need to define "most specific RDN" 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, 16 Jul 2010 08:24:48 -0000 Kaspar Brand wrote: > On 16.07.2010 03:04, Nelson B Bolyard wrote: > > Can you name any browser or other important network client made in the > > last 8 years (since RFC 3280 was published) that does SSL3 and/or TLS > > but doesn't recognize DNS names in SANs? > > "important" is a debatable term, but I'm pretty sure that as soon as you > leave the browser camp, you'll encounter quite a few... I didn't have to > search for a long time, actually: take wget as an example. Well, I got the impression that clients using openssl are generally in a bad shape. The complicated low level API, sparse docu and insecure defaults create many pitfalls for the newcomer. I hope that with the new RFC a common library that does the server id checks could be developed though. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) From nelson@bolyard.me Fri Jul 16 09:46: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 07D2F3A6A6A for ; Fri, 16 Jul 2010 09:46:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.134 X-Spam-Level: X-Spam-Status: No, score=-2.134 tagged_above=-999 required=5 tests=[AWL=0.465, 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 prWp8qYlF21q for ; Fri, 16 Jul 2010 09:46:50 -0700 (PDT) Received: from smtpauth11.prod.mesa1.secureserver.net (smtpauth11.prod.mesa1.secureserver.net [64.202.165.33]) by core3.amsl.com (Postfix) with SMTP id 041B13A6A0C for ; Fri, 16 Jul 2010 09:46:49 -0700 (PDT) Received: (qmail 18474 invoked from network); 16 Jul 2010 16:47:00 -0000 Received: from unknown (24.5.142.42) by smtpauth11.prod.mesa1.secureserver.net (64.202.165.33) with ESMTP; 16 Jul 2010 16:47:00 -0000 Message-ID: <4C408CFF.7030205@bolyard.me> Date: Fri, 16 Jul 2010 09:46:55 -0700 From: Nelson B Bolyard Organization: Network Security Services User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b1pre) Gecko/20081004 Firefox/3.5 Firefox/3.5 MIME-Version: 1.0 To: certid@ietf.org References: <201006301746.o5UHkIsE019133@fs4113.wdf.sap.corp> <4C3FB02F.3090006@bolyard.me> <4C3FEE41.5050209@velox.ch> <201007161024.53340.ludwig.nussel@suse.de> In-Reply-To: <201007161024.53340.ludwig.nussel@suse.de> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [certid] Need to define "most specific RDN" 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, 16 Jul 2010 16:46:51 -0000 On 2010-07-16 01:24 PDT, Ludwig Nussel wrote: > Kaspar Brand wrote: >> On 16.07.2010 03:04, Nelson B Bolyard wrote: >>> Can you name any browser or other important network client made in the >>> last 8 years (since RFC 3280 was published) that does SSL3 and/or TLS >>> but doesn't recognize DNS names in SANs? >> "important" is a debatable term, but I'm pretty sure that as soon as you >> leave the browser camp, you'll encounter quite a few... I didn't have to >> search for a long time, actually: take wget as an example. > > Well, I got the impression that clients using openssl are generally > in a bad shape. The complicated low level API, sparse docu and > insecure defaults create many pitfalls for the newcomer. > I hope that with the new RFC a common library that does the server > id checks could be developed though. Some of us might claim that one already exists. -- /Nelson Bolyard From paul.tiemann.usenet@gmail.com Fri Jul 16 11:02:01 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 18DDD3A67BD for ; Fri, 16 Jul 2010 11:02:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.602 X-Spam-Level: X-Spam-Status: No, score=0.602 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_28=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 oBk5xDRH2r0R for ; Fri, 16 Jul 2010 11:01:59 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id 6CE853A659C for ; Fri, 16 Jul 2010 11:01:59 -0700 (PDT) Received: by pwj1 with SMTP id 1so1233854pwj.31 for ; Fri, 16 Jul 2010 11:02:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=MKUlI322f/NDWKq3e2wWeM04CeUz1WdLYxrobLZSNew=; b=KKnmoRN04B7qAtPCjUqpliTySQpGzsOjC96hwcBSlD5oUi2o8YCFdaIoOxStjAmf1k 2DRiHpMHwyPIvusD/SG65F3atlY9Gcnqy+lO3ayUH3wQdqhVaBxafFSQzDOk4UonU7jz zkKRv6kRVRwJdVpSvMaaBB/G/YWrymCiYkFIs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=U3D83in3lJxWe84eOCLKVaDRrK/0tNp7io4+deh56S/JPwSLMBzOpeQioWAHs0mCSO E536NtWhcqao+U1tU4mSg5akvQgxXY6Ra5jdQRGAWgukLccRVNiG9HbUtO+4TMNKOSSD T+UJcblk4FqJIPGe1Z9l95aJ0GO8JEa9ZRUUY= MIME-Version: 1.0 Received: by 10.114.130.10 with SMTP id c10mr2011375wad.72.1279303330800; Fri, 16 Jul 2010 11:02:10 -0700 (PDT) Received: by 10.114.112.9 with HTTP; Fri, 16 Jul 2010 11:02:10 -0700 (PDT) In-Reply-To: <4C3E979B.4050401@velox.ch> References: <201006301746.o5UHkIsE019133@fs4113.wdf.sap.corp> <4C2B843A.5010206@stpeter.im> <4C305B93.9090001@velox.ch> <201007061435.29786.ludwig.nussel@suse.de> <4C335CE5.1090608@edelweb.fr> <4C3421B3.3070404@velox.ch> <4C3B4F6E.80903@stpeter.im> <4C3DDC18.4020808@bolyard.me> <4C3E979B.4050401@velox.ch> Date: Fri, 16 Jul 2010 12:02:10 -0600 Message-ID: From: Paul Tiemann To: certid@ietf.org Content-Type: multipart/alternative; boundary=00163645715c97ac84048b85040b Subject: Re: [certid] Need to define "most specific RDN" 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, 16 Jul 2010 19:15:41 -0000 --00163645715c97ac84048b85040b Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jul 14, 2010 at 11:07 PM, Kaspar Brand wrote: > > I'm doubtful if adding a MUST NOT for CN-IDs (vs. a SHOULD NOT) would > have a considerable impact on future CA practices. Most of them probably > don't want to risk compatibility issues with legacy implementations > (which don't recognize the subjectAltName extension). > > You're right about CAs: They'll want maximum compatibility, and there are still enough devices and clients in circulation that only do Common Name matching. See this page for a few devices that are known not to handle SANs: http://www.digicert.com/subject-alternative-name-compatibility.htm According to my research, and DigiCert's experience issuing certificates with and without SAN extensions, here is a simple hierarchy of best-to-worst compatibility for server certificates with only one FQDN (ex: www.digicert.com) to match: 1) For best compatibility, issue the certificate with CN=www.digicert.com, do not include SAN extension at all. Everything currently supports non-wildcard CN matching. Some platforms do not support wildcards (Windows Mobile 5) 2) Only slightly less compatible: issue with CN=www.digicert.com, and non-critical SAN=(dnsName=www.digicert.com) There was some talk about always including the SAN extension a few months ago on the CA/Browser forum. To try to be a good CA citizen, I went ahead and made a change so that our certificates would do this (add a 1-element SAN even if there is only one server ID to be covered by the certificate) I had to roll back, because within two days (it might have been the very next day) we got a call from a customer whose server was not accepting the certificate because the SAN extension was present. I remember it was some kind of issue with a blackberry server. I asked for details about their platform and version, but I don't believe I got them and I forgot to go back and ask again. For now, we're back to using method #1. That said, there's a good chance I could switch back to this and never hear of the problem again. At least half of all our certificates include the SAN extension and we've almost never had issues with products choking on the mere presence of the extension (that really is very rare) 3) Still less compatible: issue with CN=www.digicert.com, and CRITICAL SAN=(dnsName=www.digicert.com) When the SAN extension is marked critical, some Java based clients or servers will choke. Perhaps it's all Java versions older than 2007, but sadly that describes a fair amount of enterprise customers who run various legacy applications on very old JVM versions. 4) Least compatible: issue with CN=DigiCert, Inc or no CN at all, and non-critical SAN=(dnsName=www.digicert.com) I agree with Nelson's recent post, however, that I would prefer it if the CN were restricted to just one spot. There are too many browsers already behaving differently when there are more than one CN in a subject. Dan Kaminsky found Firefox, IE, and openssl behave differently when they see more than one CN in a subject. Almost all certificates I'm aware of have only one CN in them -- and making it even more rare would be a step forward in my opinion. My opinion on steps for improvement from where we are now: 1) Clarify CN usage by strongly recommending only 1 CN in a subject. 2) Encourage ubiquitous usage of the SAN extension, so that almost all CA issued certificates include the SAN extension, only deviating from that for reasons of compatibility with legacy servers or clients which choke on the SAN. 3) Make strong recommendations to stop using CN-IDs in subject 4) Stop using server-IDs in common names experimentally On the topic of name constraints: What if there are ways to push Name Constraints forward without necessarily having to wait for all legacy clients to die and all the niche clients to become compatible? Here's one idea (admittedly not past v0.1 in my head) 1) Have the major browser vendors add a small mechanism to detect certificates with Name Constraint violations, and give them a central, automated way to "report" a certificate found with violated name constraints which might pose a risk for all the non-compliant browsers and clients. With something like that in place, the major browsers will be able to handle name constraints correctly, and the constraints policing feature would help to erase the incentive that the operator of a constrained CA certificate would have for violating the constraints to trick legacy devices. 2) NetCraft could possibly help with Name Constraints monitoring, at least for the public internet. 3) Eventually at some date in the distant future, all the legacy devices will be dead, and all clients will be compatible, and the programs in #1 and #2 could be dismantled. Paul Tiemann (CTO, DigiCert) --00163645715c97ac84048b85040b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wed, Jul 14, 2010 at 11:07 PM, Kaspar= Brand <ietf-c= ertid@velox.ch> wrote:

I'm doubtful if adding a MUST NOT for CN-IDs (vs. a SHOULD NOT) would have a considerable impact on future CA practices. Most of them probably don't want to risk compatibility issues with legacy implementations
(which don't recognize the subjectAltName extension).

=A0
You're right about CAs:=A0 They'll want maxim= um compatibility, and=20 there are still enough devices and clients in circulation that only do=20 Common Name matching.=A0

See this page for a few devices that are known not to handle SANs:
<= br>http://www.digicert.com/subject-alternative-name-c= ompatibility.htm

According to my research, and DigiCert's experience issuing=20 certificates with and without SAN extensions, here is a simple hierarchy of best-to-worst compatibility for server certificates with only one=20 FQDN (ex: www.digice= rt.com) to match:

1) For best compatibility, issue the certificate with CN=3Dwww.digicert.com, do=20 not include SAN extension at all.

Everything currently supports=20 non-wildcard CN matching.=A0 Some platforms do not support wildcards=20 (Windows Mobile 5)

2) Only slightly less compatible: issue with CN=3Dwww.digicert.com, and non-critical SAN=3D(dnsName=3Dwww.digicert.com)

There was some talk about=20 always including the SAN extension a few months ago on the CA/Browser=20 forum.=A0 To try to be a good CA citizen, I went ahead and made a change=20 so that our certificates would do this (add a 1-element SAN even if=20 there is only one server ID to be covered by the certificate)

I had to roll back, because within two days (it might have been the=20 very next day) we got a call from a customer whose server was not=20 accepting the certificate because the SAN extension was present.=A0 I=20 remember it was some kind of issue with a blackberry server.=A0 I asked=20 for details about their platform and version, but I don't believe I got= =20 them and I forgot to go back and ask again.=A0 For now, we're back to= =20 using method #1.

That said, there's a good chance I could switch back to this and=20 never hear of the problem again.=A0 At least half of all our certificates= =20 include the SAN extension and we've almost never had issues with=20 products choking on the mere presence of the extension (that really is=20 very rare)

3) Still less compatible: issue with CN=3Dwww.digicert.com, and CRITICAL SAN=3D(dnsName=3Dwww.digicert.com)

When the SAN extension is marked critical, some Java based clients or=20 servers will choke.=A0 Perhaps it's all Java versions older than 2007, = but sadly that describes a fair amount of enterprise customers who run=20 various legacy applications on very old JVM versions.

4) Least compatible: issue with CN=3DDigiCert, Inc or no CN at all,=20 and non-critical SAN=3D(dnsName=3Dwww.digicert.com)

I agree with Nelson's=20 recent post, however, that I would prefer it if the CN were restricted=20 to just one spot.=A0 There are too many browsers already behaving=20 differently when there are more than one CN in a subject.=A0 Dan Kaminsky= =20 found Firefox, IE, and openssl behave differently when they see more=20 than one CN in a subject.=A0 Almost all certificates I'm aware of have= =20 only one CN in them -- and making it even more rare would be a step=20 forward in my opinion.=A0

My opinion on steps for improvement from where we are now:

1) Clarify CN usage by strongly recommending only 1 CN in a subject.
2) Encourage ubiquitous usage of the SAN extension, so that almost all CA=20 issued certificates include the SAN extension, only deviating from that=20 for reasons of compatibility with legacy servers or clients which choke=20 on the SAN.
3) Make strong recommendations to stop using CN-IDs in subject
4)=20 Stop using server-IDs in common names experimentally

On the topic of name constraints: What if there are ways to push Name Constraints=20 forward without necessarily having to wait for all legacy clients to die and all the niche clients to become compatible?=A0 Here's one idea=20 (admittedly not past v0.1 in my head)

1) Have the major browser vendors add a small mechanism to detect=20 certificates with Name Constraint violations, and give them a central,=20 automated way to "report" a certificate found with violated name= =20 constraints which might pose a risk for all the non-compliant browsers=20 and clients.=A0 With something like that in place, the major browsers will be able to handle name constraints correctly, and the constraints=20 policing feature would help to erase the incentive that the operator of a constrained CA certificate would have for violating the constraints to=20 trick legacy devices.=A0
2) NetCraft could possibly help with Name Constraints monitoring, at=20 least for the public internet.
3) Eventually at some date in the=20 distant future, all the legacy devices will be dead, and all clients=20 will be compatible, and the programs in #1 and #2 could be dismantled.

Paul Tiemann
(CTO, DigiCert)
--00163645715c97ac84048b85040b-- From mrex@sap.com Fri Jul 16 17:53:55 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 DC1943A6765 for ; Fri, 16 Jul 2010 17:53:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.855 X-Spam-Level: X-Spam-Status: No, score=-7.855 tagged_above=-999 required=5 tests=[AWL=-0.806, BAYES_50=0.001, HELO_EQ_DE=0.35, J_CHICKENPOX_28=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 cen7IJ8meqVH for ; Fri, 16 Jul 2010 17:53:54 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by core3.amsl.com (Postfix) with ESMTP id 0FE583A6407 for ; Fri, 16 Jul 2010 17:53:53 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id o6H0s3m8002883 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 17 Jul 2010 02:54:03 +0200 (MEST) From: Martin Rex Message-Id: <201007170054.o6H0s28q023476@fs4113.wdf.sap.corp> To: paul.tiemann.usenet@gmail.com (Paul Tiemann) Date: Sat, 17 Jul 2010 02:54:02 +0200 (MEST) In-Reply-To: from "Paul Tiemann" at Jul 16, 10 12:02:10 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] Need to define "most specific RDN" 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: Sat, 17 Jul 2010 00:53:56 -0000 Paul Tiemann wrote: > > 2) Only slightly less compatible: issue with CN=www.digicert.com, and > non-critical SAN=(dnsName=www.digicert.com) This is what has been in common use over the past 15 years, what makes the most sense and what is the most interoperable. A "Best Common Practice" (BCP) document ought to be about what is in use and known to work well, not about some folks disliking what is there and trying to exert undue pressure and chastise an installed base that is working perfectly fine. I do not have a problem with browsers or other application clients that ignore CN-IDs whenever there is a SAN extension DNSName present in a servers cert. But I have a problem with words in a BCP that are in clear violation of rfc-2119 section 6 last sencence with the potential to cause interop problems and entirely without a cause. > > 3) Still less compatible: issue with CN=www.digicert.com, and CRITICAL > SAN=(dnsName=www.digicert.com) What is the purpose of marking SAN critical other than having a number of peers choke on it and reject it? It's hardly make a cert more understandable. An implementation of PKI has no control over what exactly an application does with a SAN. > > When the SAN extension is marked critical, some Java based clients or > servers will choke. Perhaps it's all Java versions older than 2007, but > sadly that describes a fair amount of enterprise customers who run various > legacy applications on very old JVM versions. If the J2EE versions out there would be 100% backwards compatible, then this problem would be insignificant. Unfortunately, due to a lack of planning, there seems to be a release-specific lock-in. > > 4) Least compatible: issue with CN=DigiCert, Inc or no CN at all, and > non-critical SAN=(dnsName=www.digicert.com) No CN would be a pretty bad idea. If I look at the administrative interfaces, the "handle" to a digital identity is normally it's CN= content, i.e. when administering IIS server certs on W2K3. And if you google around, the amount of documentation that instructs you to have the fqdn hostname in the CN= part of the cert just everywhere, the only document that doesn't is the current I-D. > > I agree with Nelson's recent post, however, that I would prefer it if the CN > were restricted to just one spot. There are too many browsers already > behaving differently when there are more than one CN in a subject. Dan > Kaminsky found Firefox, IE, and openssl behave differently when they see > more than one CN in a subject. Almost all certificates I'm aware of have > only one CN in them -- and making it even more rare would be a step forward > in my opinion. I do _not_ like the idea to make multiple CN= matching part of the standard. The clients that match on more than one CN= are quite few (mine does), it never was part of any standard or suggestion and the behaviour of clients in presence of multiple CN-IDs is difficult to predict. Documenting what is there would be reasonable though, i.e. Most clients will match CN-ID when no SANs are present, but only the most specific. Having multiple CN-IDs in a subject name was never recommended, and only a few clients implement it that way. Since there are some commercial CAs do a poor job of vetting subject name components for the CSRs they receive, matching multiple CN-IDs could make a client that trusts one of those negligent CAs vulnerable to server identity spoofing. Having the fqdn server name as a CN-ID in the server certificate is a well-established tradition, documented in that fashion everywhere, and many adminstrative user interfaces use the CN part of the subject distinguished name of a certificate as the prominent identifier and distinguisher. > > My opinion on steps for improvement from where we are now: > > 1) Clarify CN usage by strongly recommending only 1 CN in a subject. OK. Makes sense. > 2) Encourage ubiquitous usage of the SAN extension, so that almost all CA > issued certificates include the SAN extension, only deviating from that for > reasons of compatibility with legacy servers or clients which choke on the > SAN. OK. Makes sense. > > 3) Make strong recommendations to stop using CN-IDs in subject Really bad idea, completely unnecesary and clear violation of rfc-2116 section 6. Im pretty sure that every one which strongly cares about this can make his client ignore CN-IDs when at least one DNSName SAN is present, so 2) is perfectly sufficient. > > 4) Stop using server-IDs in common names experimentally All the big players have implemented IPv6 and tested interop. Why don't we shutdown the entire IPv4 internet to force the users to use IPv6? > > On the topic of name constraints: What if there are ways to push Name > Constraints forward without necessarily having to wait for all legacy > clients to die and all the niche clients to become compatible? Here's one > idea (admittedly not past v0.1 in my head) > > 1) Have the major browser vendors add a small mechanism to detect > certificates with Name Constraint violations, and give them a central, > automated way to "report" a certificate found with violated name constraints > which might pose a risk for all the non-compliant browsers and clients. Huh? For the preconfigured trusted CAs shipping with browsers, name constraints are entirely irrelevent, just as irrelevant to most of the users out there. Name constraints might be interesting to individual large and hierarchical organizations that run a CA hierarchy and delegate authority constrained to name spaces or domains. On the other hand, I remeber a really large multi-national (US-originating) company that doesn't run company-internal CAs because of liability issues. Which puzzles me, because I believe their legal department is more sophisticated and experienced than ours, and we've been operating CAs for company-internal purposes for more than a decade... But what has name constraints to do with CN-ID? An organization that can operate a CA hierachy and configure name constraints, should be perfectly able to equip all of their server certs with SANs, in which case the software of all of the "MUST ignore CN-ID if DNSName SAN is present" will reliably ignore the CN-ID, so that it means no harm. -Martin PS: Are you aware that processing name constraints for DNSName SANs is still optional in rfc-5280 ("RECOMMENDED"), whereas processing name constraints for DirectoryName was already a requirement ("MUST") in rfc-2459? From nelson@bolyard.me Sat Jul 17 15:45: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 0138B3A6A0B for ; Sat, 17 Jul 2010 15:45:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.989 X-Spam-Level: X-Spam-Status: No, score=-0.989 tagged_above=-999 required=5 tests=[AWL=-0.990, 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 AtGiuNvt8NhK for ; Sat, 17 Jul 2010 15:45:33 -0700 (PDT) Received: from smtpauth03.prod.mesa1.secureserver.net (smtpauth03.prod.mesa1.secureserver.net [64.202.165.183]) by core3.amsl.com (Postfix) with SMTP id 51E7D3A6A08 for ; Sat, 17 Jul 2010 15:45:22 -0700 (PDT) Received: (qmail 20451 invoked from network); 17 Jul 2010 22:45:33 -0000 Received: from unknown (24.5.142.42) by smtpauth03.prod.mesa1.secureserver.net (64.202.165.183) with ESMTP; 17 Jul 2010 22:45:33 -0000 Message-ID: <4C42328B.4070305@bolyard.me> Date: Sat, 17 Jul 2010 15:45:31 -0700 From: Nelson B Bolyard Organization: Network Security Services User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b1pre) Gecko/20081004 Firefox/3.5 Firefox/3.5 MIME-Version: 1.0 To: certid@ietf.org References: <201007170054.o6H0s28q023476@fs4113.wdf.sap.corp> In-Reply-To: <201007170054.o6H0s28q023476@fs4113.wdf.sap.corp> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [certid] Need to define "most specific RDN" 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, 17 Jul 2010 22:45:35 -0000 On 2010-07-16 17:54 PDT, Martin Rex wrote: > But I have a problem with words in a BCP that > are in clear violation of rfc-2119 section 6 last sencence > with the potential to cause interop problems and entirely without > a cause. Fair enough, but I challenge your implicit assertions that there is any "clear violation" or that they are "without cause". > What is the purpose of marking SAN critical other than having a > number of peers choke on it and reject it? It's hardly make a > cert more understandable. An implementation of PKI has no control > over what exactly an application does with a SAN. It is obviously to ensure that any relying party relies on the content of the SAN. An issuer DOES have control. It ensures that the relying party will NOT rely on the cert if it does not grok the SAN. >> 3) Make strong recommendations to stop using CN-IDs in subject > > Really bad idea, completely unnecesary and clear violation of > rfc-2116 section 6. Baloney. May I suggest you re-read that section of the RFC you most frequently cite? "Making strong recommendations" is not the same as "Imperative" or "MUST" and you know it. But further, section 6 allows imperatives for "behavior which has potential for causing harm". Allow subordinate CAs to issue certs that bypass the name constraints placed on them is most definitely "behavior which has potential for causing harm". > Im pretty sure that every one which strongly cares about this can > make his client ignore CN-IDs when at least one DNSName SAN is > present, so 2) is perfectly sufficient. Only after CAs stop issuing certs without SANs. I read Paul's message as saying that Digicert is issuing certs without SANs. (Paul, please correct me if that is mistaken.) >> 4) Stop using server-IDs in common names experimentally A great idea. Especially if the only affected products are really old cell phones that cannot handle modern web sites anyway. Continue to have special wifi.domain.TLD web sites for them, and let the rest of the Internet move ahead. > All the big players have implemented IPv6 and tested interop. > Why don't we shutdown the entire IPv4 internet to force the > users to use IPv6? Martin, you oppose experimentation? Do you want to live in the past forever? >> On the topic of name constraints: What if there are ways to push Name >> Constraints forward without necessarily having to wait for all legacy >> clients to die and all the niche clients to become compatible? Firefox already applies DNS name constraints to DNS names in SANs, and has for years. In a forthcoming version of Firefox, DNS name constraints WILL be applied to last Subject CN under the following circumstances: - The cert chain being verified is being verified for the purpose of being an SSL/TLS server certificate - the server cert has no SAN extension, or no DNS names in its SAN extension (in other words, under the same circumstances in which we would use the last Subject CN as a CN-ID for cert name matching purposes). The value of these name constraints is that they will enable CAs to issue subordinate CA certs to corporations without any fear that those corporations will issue false certs for their competitors. They also allow relying parties to constrain names in entire PKI trees subordinate to certain national CAs, thereby greatly reducing vulnerability to the compelled issuance of certificates for domains outside that CA's national country code domain(s). Without doubt, the threat of compelled issuance has been the single biggest threat to public confidence in PKI to have come along in years, and name constraints are one of the few ways we have of combating that threat. So, don't dismiss it lightly. From Jeff.Hodges@KingsMountain.com Sun Jul 18 15:36:52 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 8113C3A69AA for ; Sun, 18 Jul 2010 15:36:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.51 X-Spam-Level: X-Spam-Status: No, score=-1.51 tagged_above=-999 required=5 tests=[AWL=0.755, BAYES_00=-2.599, 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 vZoF4-LCh5Q3 for ; Sun, 18 Jul 2010 15:36:43 -0700 (PDT) Received: from cpoproxy3-pub.bluehost.com (cpoproxy3-pub.bluehost.com [67.222.54.6]) by core3.amsl.com (Postfix) with SMTP id 88A5A3A6947 for ; Sun, 18 Jul 2010 15:35:54 -0700 (PDT) Received: (qmail 14761 invoked by uid 0); 18 Jul 2010 22:36:05 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by cpoproxy3.bluehost.com with SMTP; 18 Jul 2010 22:36:05 -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=6IpZK440YBPfjbYqtf67OwdT0brB/K/RrRhDcmgiQw+i5Gs2IYqfeSrcvf5iVZqY3/YqbekgYvboL/ZjCKWDXF8AW6mY6qvPOkqMcFv5xW3Az1uyll/zn5DY2fSh21h/; Received: from c-24-4-122-173.hsd1.ca.comcast.net ([24.4.122.173] helo=[192.168.11.10]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1OacSr-0001dP-Cg for certid@ietf.org; Sun, 18 Jul 2010 16:36:05 -0600 Message-ID: <4C4381D3.8010707@KingsMountain.com> Date: Sun, 18 Jul 2010 15:36:03 -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 24.4.122.173 authed with jeff.hodges+kingsmountain.com} Subject: Re: [certid] Last Call: draft-saintandre-tls-server-id-check 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: Sun, 18 Jul 2010 22:36:53 -0000 hey folks, We're getting feedback on the ietf@ietf.org list wrt draft-saintandre-tls-server-id-check. In particular, there's a question about the requirement to order the list of reference identifiers in section "4.2. Constructing an Ordered List of Reference Identifiers" that would be good to have implementors (in particular) weigh in on. i.e. is the ordering requirement strictly necessary protocol-wise? Is it (only) perhaps an implementation hint? thanks, =JeffH From ietf-certid@velox.ch Sun Jul 18 22:35:13 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 664953A69DC for ; Sun, 18 Jul 2010 22:34:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.072 X-Spam-Level: X-Spam-Status: No, score=-1.072 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_05=-1.11] 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 xitytVPHebSd for ; Sun, 18 Jul 2010 22:34:27 -0700 (PDT) Received: from appendix.velox.ch (appendix.velox.ch [62.75.148.60]) by core3.amsl.com (Postfix) with ESMTP id A5FE73A69DF for ; Sun, 18 Jul 2010 22:34:16 -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 o6J5XisY003655 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 19 Jul 2010 07:33:45 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=velox.ch; s=appendix-177f; t=1279517625; bh=wWnEYHyu3Uhvz74jYwunnL7fdEj0JjnkD9hazOqKuFo=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=ELL09vHSRxZ1M5ps9vXtoivMOaNlffd/pf5YgeQOgnV9eArw6xq+orU3NkzhkqDns JPCYYQbh3BLEK8ZbW+iBlMxoiMfmSlDlxYgedvoAO+JAFlOQK0eObr8DA5MgNoVuvi ECDmWcyVCtw/opiWOiOUCLMi7WTnZ6FKAR67qW8xu01a22NXW84eCXtAvdPAfUaAbA 7e+OqxhvCAFyPx3SfzPHwE1v/5J2dlydCGWCEs8Bw9+oyd55qmkCQpmHpLOj09iJXp TGHmvEBHl6XygjQWvSmo+LC1j/anHFyU2e0xZTpBwMDn5sEbhafaei2OUaZsbpG/+i GMJR0R+jXrFCw== Message-ID: <4C43E3B9.6040004@velox.ch> DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=velox.ch; s=cortex-8a58; t=1279517623; bh=wWnEYHyu3Uhvz74jYwunnL7fdEj0JjnkD9hazOqKuFo=; h=Date:From:MIME-Version:To:Subject:References:In-Reply-To: Content-Type:Content-Transfer-Encoding; b=JUrFRNwA9ohGFh65TPjQXQWKTmjQYGOcH0k4AsjmoMPL/bIkMfUPexE/4nbBahwAI wtiPNKjEzH7pr4mkqA/UwqARqQNig5BlsMy9ObfcKRZ3mhgEvVnecivyw+68hJJz8S hMheGYSELLLBqmbo5V7q6r4IbHocouotoA7K3w1KZDmDrcx4WeURNqyIwxzqF1E2wE WawIDWfWyUSJD8eluHf7iNmFkr+6fxGWLdyym+zKnltkXIl5VfGxwDfpSOmuqFPKmA FwYNAiHpuNvpVs6msKaFyMgKU1HBPUNEXCPx/9bL0ydROtyf+EVbVkolms0M6YeIes brg80w6CChzyQ== Date: Mon, 19 Jul 2010 07:33:45 +0200 From: Kaspar Brand User-Agent: Thunderbird/3.x MIME-Version: 1.0 To: certid@ietf.org References: <201007170054.o6H0s28q023476@fs4113.wdf.sap.corp> In-Reply-To: <201007170054.o6H0s28q023476@fs4113.wdf.sap.corp> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [certid] Need to define "most specific RDN" 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, 19 Jul 2010 05:35:44 -0000 On 17.07.2010 02:54, Martin Rex wrote: > I do _not_ like the idea to make multiple CN= matching part of the > standard. The clients that match on more than one CN= are quite few > (mine does), it never was part of any standard or suggestion Nor would I consider the wording "the (most specific) Common Name field in the Subject field of the certificate" from RFC 2818 to be authoritative or "part of a standard". Some implementers apparently attached much importance to "(most specific)" in their reading of this text, but I still wonder what the real intention was when that term was added to / coined in RFC 2818. [1] Just to be clear: I'm not advocating that CAs put multiple CNs into the subject DN: I'm completely fine with having a strong recommendation in section 3 ("Representation of Server Identity") for a single CN in the subject only. In section 4 ("Verification of Server Identity"), however, I think we should expressly put an end to the debate of what "(most specific)" in RFC 2818 really means, otherwise the confusion is perpetuated. Of the two solutions - either explain at great length how it is to be understood DER-encoding-wise, or just go loop over all CNs -, the latter definitely seems preferrable to me. Kaspar [1] Looking through http://www.imc.org/ietf-apps-tls/mail-archive/maillist.html didn't give a clue, unfortunately. From mrex@sap.com Mon Jul 19 09:12:24 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 3FC3A3A6893 for ; Mon, 19 Jul 2010 09:12:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.115 X-Spam-Level: X-Spam-Status: No, score=-8.115 tagged_above=-999 required=5 tests=[AWL=-0.466, 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 35aPM++itirc for ; Mon, 19 Jul 2010 09:12:19 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 154283A690F for ; Mon, 19 Jul 2010 09:12:05 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id o6JGCEqU005150 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 19 Jul 2010 18:12:14 +0200 (MEST) From: Martin Rex Message-Id: <201007191612.o6JGCEnr008883@fs4113.wdf.sap.corp> To: nelson@bolyard.me (Nelson B Bolyard) Date: Mon, 19 Jul 2010 18:12:14 +0200 (MEST) In-Reply-To: <4C42328B.4070305@bolyard.me> from "Nelson B Bolyard" at Jul 17, 10 03:45:31 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] Need to define "most specific RDN" 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, 19 Jul 2010 16:12:24 -0000 Nelson B Bolyard wrote: > > > What is the purpose of marking SAN critical other than having a > > number of peers choke on it and reject it? It's hardly make a > > cert more understandable. An implementation of PKI has no control > > over what exactly an application does with a SAN. > > It is obviously to ensure that any relying party relies on the content > of the SAN. An issuer DOES have control. It ensures that the relying > party will NOT rely on the cert if it does not grok the SAN. The criticality is on the entire SAN extension, not on a particular name, and the critically is usually visible only to the PKI part of the software stack. Apps don't care, and should not have to--in particular, when they're seperate from the PKI stuff by several layers of abstractions. If there is an existing SPKM-like GSS-API mechanism that uses Subject DNames at the GSS-API level, what should it do when encountering a cert with a subjectAltName marked critical? The two possibilities are either choke on it or ignore it. The PKI software underlying this GSS-API might recognize subjectAltNames, just that the GSS-API mechanism wrapper above might not be looking at/form them at all. There is at least one partner who has built a gssapi-mechanism with OpenSSL, wrapping SSL-records into GSS-API tokens. One thing that I find particularly irritating in -08 is that it completely ignores a much more secure authentication scheme for servers, by clients knowing the entire subject DName of a certificate rather than matching only a single name component. 4.2. Constructing an Ordered List of Reference Identifiers o The list MUST include a DNS-ID. A reference identifier of type DNS-ID can be directly constructed from a fully-qualified DNS domain name that is (a) contained in or securely derived from the inputs (i.e., the source domain), or (b) explicitly associated with the source domain by means of user configuration (i.e., a target domain). [...] Security 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. Comparing the full DName is always more secure than comparing only CN-ID, so this Security Note is factually flawed. In that respect, rfc-2818 is much more reasonable: If the client has external information as to the expected identity of the server, the hostname check MAY be omitted. (For instance, a client may be connecting to a machine whose address and hostname are dynamic but the client knows the certificate that the server will present.) In such cases, it is important to narrow the scope of acceptable certificates as much as possible in order to prevent man in the middle attacks. > > >> 3) Make strong recommendations to stop using CN-IDs in subject > > > > Really bad idea, completely unnecesary and clear violation of > > rfc-2116 section 6. > > Baloney. May I suggest you re-read that section of the RFC you most > frequently cite? "Making strong recommendations" is not the same as > "Imperative" or "MUST" and you know it. Personally, I count an underexplained SHOULD NOT as an imperative, about as much as you appear to be assuming the presence of DNSName SAN name constraints to be an imperative. There is absolutely no problem whatsoever with how reasonable CAs use and issue Server-Certs with CN-ID, and similarly, there is absolutely no problem whatsoever with clients matching CN-IDs. The general approach of rfc-2818 is *MUCH* more reasonable. Instead of lamenting on CN-ID, it simply declares them as deprecated and suggests how to do server endpoint identification in the future. In particular it does NOT mess around with existing practice (in documentation, in implementations and in CA practices). Describing how CAs should issue Certs with DName-SANs for a certain purpose is OK. Describing potential security issues and implementation inconsistencies with CN-ID is also OK. But trying to change rules for Subject DName to something that differs considerably from existing documentation, existing implementations and existing practise is inappropriate. After all, CN-ID has been deprecated for many years. > > But further, section 6 allows imperatives for "behavior which has > potential for causing harm". Allow subordinate CAs to issue certs that > bypass the name constraints placed on them is most definitely "behavior > which has potential for causing harm". Implementing name constraints for DNSName SANs is optional. And an subordinate CA that wants to issue Certs using CN-IDs for bypassing DNSName SAN Name constraints is certainly not going to be stopped by a "MUST NOT issue" guidance in a BCP document. A subordinate CA is more likely to be held responsible for issuing certs not incompliance with the policies of it's parent CA than by ignoring a SHOULD NOT in some RFC document. The only behaviour clearly causing harm are some commercial CAs which disclaim libabilities for blindly copying unvetted DName components from the CSR they receive into the Certs they issue. > > > Im pretty sure that every one which strongly cares about this can > > make his client ignore CN-IDs when at least one DNSName SAN is > > present, so 2) is perfectly sufficient. > > Only after CAs stop issuing certs without SANs. I read Paul's message as > saying that Digicert is issuing certs without SANs. (Paul, please correct > me if that is mistaken.) Why? You mean that there are CAs that issue Server certs _without_ SANs and CN-IDs that you have to be afraid of? Why would you be less afraid if they issued certs with DNSName SANs, and why do you trust such CAs in the first place? > > >> 4) Stop using server-IDs in common names experimentally > > A great idea. Especially if the only affected products are really old cell > phones that cannot handle modern web sites anyway. Continue to have special > wifi.domain.TLD web sites for them, and let the rest of the Internet move > ahead. Most software on top of OpenSSL checks CN-IDs only. > > > All the big players have implemented IPv6 and tested interop. > > Why don't we shutdown the entire IPv4 internet to force the > > users to use IPv6? > > Martin, you oppose experimentation? > Do you want to live in the past forever? What you are suggesting is involuntary euthanasia. I violently oppose the creation of interop problems in order to discriminate against an installed base, especially when there is no problem with the existing scheme to have old and new coexist peacefully together. > > >> On the topic of name constraints: What if there are ways to push Name > >> Constraints forward without necessarily having to wait for all legacy > >> clients to die and all the niche clients to become compatible? > > Firefox already applies DNS name constraints to DNS names in SANs, and > has for years. In a forthcoming version of Firefox, DNS name constraints > WILL be applied to last Subject CN under the following circumstances: > > - The cert chain being verified is being verified for the purpose of being > an SSL/TLS server certificate > - the server cert has no SAN extension, or no DNS names in its SAN extension > > (in other words, under the same circumstances in which we would use the > last Subject CN as a CN-ID for cert name matching purposes). > > The value of these name constraints is that they will enable CAs to issue > subordinate CA certs to corporations without any fear that those > corporations will issue false certs for their competitors. So you are abusing Firefox to protect an inter-CA business model? For the end user this is completely irrelevant. > > They also allow relying parties to constrain names in entire PKI trees > subordinate to certain national CAs, thereby greatly reducing vulnerability > to the compelled issuance of certificates for domains outside that CA's > national country code domain(s). HUH? Name constraints work only within one single hierarchy. As soon as you have two independent trusted Roots, name constraints no longer work. Browsers come preloaded/pretrusted with ~40 independent Roots. -Martin From mrex@sap.com Mon Jul 19 09:57:39 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 D11453A6B37 for ; Mon, 19 Jul 2010 09:57:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.393 X-Spam-Level: X-Spam-Status: No, score=-9.393 tagged_above=-999 required=5 tests=[AWL=0.856, BAYES_00=-2.599, 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 AzPoistm-obE for ; Mon, 19 Jul 2010 09:57:37 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by core3.amsl.com (Postfix) with ESMTP id 81BC83A6B00 for ; Mon, 19 Jul 2010 09:57:37 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id o6JGvowa000180 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 19 Jul 2010 18:57:51 +0200 (MEST) From: Martin Rex Message-Id: <201007191657.o6JGvoFU011620@fs4113.wdf.sap.corp> To: ietf-certid@velox.ch (Kaspar Brand) Date: Mon, 19 Jul 2010 18:57:50 +0200 (MEST) In-Reply-To: <4C43E3B9.6040004@velox.ch> from "Kaspar Brand" at Jul 19, 10 07:33:45 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal06 X-SAP: out Cc: certid@ietf.org Subject: Re: [certid] Need to define "most specific RDN" 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, 19 Jul 2010 16:57:39 -0000 Kaspar Brand wrote: > > In section 4 ("Verification of Server Identity"), however, I think we > should expressly put an end to the debate of what "(most specific)" in > RFC 2818 really means, otherwise the confusion is perpetuated. I would prefer to stick with the _exact_ description of rfc-2818. After all, this method has been deprecated back then and is intended to remain deprecated. > Of the two solutions - either explain at great length how it is to be > understood DER-encoding-wise, or just go loop over all CNs -, the latter > definitely seems preferrable to me. RFC2818 is likely a specification looking backwards, trying to describe the current practice and the behaviour of existing implementations. A lot of TLS clients and most web browsers had been checking only one single CN-ID when RFC-2818 was written (and still do), and the "most specific" is likely the attempt to indicate which CN-ID they are checking. To me it sounds like the first match on a string search based on the reversed ordering in "String Representation of Distinguished Names" (rfc2253 as far as rfc2818 is concerned, which has since been obsoleted by rfc-4514). But frankly, I do no see much value in trying to describe all possible interpretation of a fairly vague wording, that itself was an attempt to characterize, NOT specify, what kind of behaviour there is in the installed base. Leaving the vague description of rfc-2818 as is, and pointing out more prominently that it is really deprecated should be perfectly sufficient. -Martin From shuque@isc.upenn.edu Mon Jul 19 21:13:06 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 B7C3C3A69CF for ; Mon, 19 Jul 2010 21:13:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.413 X-Spam-Level: X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=0.186, 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 5c-cTL54hzuC for ; Mon, 19 Jul 2010 21:12:56 -0700 (PDT) Received: from talkeetna.isc-net.upenn.edu (TALKEETNA.isc-net.upenn.edu [128.91.197.188]) by core3.amsl.com (Postfix) with ESMTP id 942053A68A3 for ; Mon, 19 Jul 2010 21:12:52 -0700 (PDT) Received: by talkeetna.isc-net.upenn.edu (Postfix, from userid 4127) id 84A5B2138; Tue, 20 Jul 2010 00:13:07 -0400 (EDT) Date: Tue, 20 Jul 2010 00:13:07 -0400 From: Shumon Huque To: Martin Rex Message-ID: <20100720041307.GA5313@isc.upenn.edu> References: <4C43E3B9.6040004@velox.ch> <201007191657.o6JGvoFU011620@fs4113.wdf.sap.corp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201007191657.o6JGvoFU011620@fs4113.wdf.sap.corp> User-Agent: Mutt/1.4.2.1i Organization: University of Pennsylvania Cc: certid@ietf.org, Kaspar Brand Subject: Re: [certid] Need to define "most specific RDN" 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, 20 Jul 2010 04:13:07 -0000 On Mon, Jul 19, 2010 at 06:57:50PM +0200, Martin Rex wrote: > [...] > But frankly, I do no see much value in trying to describe all possible > interpretation of a fairly vague wording, that itself was an attempt > to characterize, NOT specify, what kind of behaviour there is in the > installed base. Leaving the vague description of rfc-2818 as is, > and pointing out more prominently that it is really deprecated > should be perfectly sufficient. > > -Martin I'm in full agreement. -- Shumon Huque University of Pennsylvania. From mrex@sap.com Wed Jul 21 16:12: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 B9BBE3A6857 for ; Wed, 21 Jul 2010 16:12:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.469 X-Spam-Level: X-Spam-Status: No, score=-9.469 tagged_above=-999 required=5 tests=[AWL=0.780, BAYES_00=-2.599, 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 rr4aA8aDawqJ for ; Wed, 21 Jul 2010 16:12:34 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 8210F3A6824 for ; Wed, 21 Jul 2010 16:12:34 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id o6LNCjn0024645 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 22 Jul 2010 01:12:45 +0200 (MEST) From: Martin Rex Message-Id: <201007212312.o6LNCi8Y017372@fs4113.wdf.sap.corp> To: nelson@bolyard.me (Nelson B Bolyard) Date: Thu, 22 Jul 2010 01:12:44 +0200 (MEST) In-Reply-To: <4C3DDC18.4020808@bolyard.me> from "Nelson B Bolyard" at Jul 14, 10 08:47:36 am 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] Need to define "most specific RDN" 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, 21 Jul 2010 23:12:37 -0000 Nelson B Bolyard wrote: > > SANs solve this whole problem. They have a component that may ONLY contain > DNS names, and therefore is easily constrained. DNS name constraints would > be effective if certs ONLY put DNS names into SANs. But putting DNS names > into SANs effectively bypasses name constraints (at least, in > implementations I tested last year). Look at the server certificate here(*): https://edgecastcdn.net/ and SANs in it. The Server cert is from a 3-level CA hierarchy (Entrust on top, two intermediate CAs from DigiCert). How exactly are name constraints going to make issuing such certs easier or safer, and can you actually come up with a meaningful name constraints for such a cert? -Martin (*) Server cert example found here: http://www.imperialviolet.org/2010/06/25/overclocking-ssl.html recently mentioned on this list. From shuque@isc.upenn.edu Wed Jul 21 19:57:22 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 2E7DA3A68F5 for ; Wed, 21 Jul 2010 19:57:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.713 X-Spam-Level: X-Spam-Status: No, score=-4.713 tagged_above=-999 required=5 tests=[AWL=-2.114, 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 Z4dUL78Q+WKD for ; Wed, 21 Jul 2010 19:57:21 -0700 (PDT) Received: from talkeetna.isc-net.upenn.edu (TALKEETNA.isc-net.upenn.edu [128.91.197.188]) by core3.amsl.com (Postfix) with ESMTP id 1C4D63A6892 for ; Wed, 21 Jul 2010 19:57:21 -0700 (PDT) Received: by talkeetna.isc-net.upenn.edu (Postfix, from userid 4127) id A48092138; Wed, 21 Jul 2010 22:57:37 -0400 (EDT) Date: Wed, 21 Jul 2010 22:57:37 -0400 From: Shumon Huque To: Martin Rex Message-ID: <20100722025737.GA5345@isc.upenn.edu> References: <4C3DDC18.4020808@bolyard.me> <201007212312.o6LNCi8Y017372@fs4113.wdf.sap.corp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201007212312.o6LNCi8Y017372@fs4113.wdf.sap.corp> User-Agent: Mutt/1.4.2.1i Organization: University of Pennsylvania Cc: certid@ietf.org Subject: Re: [certid] Need to define "most specific RDN" 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, 22 Jul 2010 02:57:22 -0000 On Thu, Jul 22, 2010 at 01:12:44AM +0200, Martin Rex wrote: > Nelson B Bolyard wrote: > > > > SANs solve this whole problem. They have a component that may ONLY contain > > DNS names, and therefore is easily constrained. DNS name constraints would > > be effective if certs ONLY put DNS names into SANs. But putting DNS names > > into SANs effectively bypasses name constraints (at least, in > > implementations I tested last year). > > Look at the server certificate here(*): > > https://edgecastcdn.net/ > > and SANs in it. The Server cert is from a 3-level CA hierarchy > (Entrust on top, two intermediate CAs from DigiCert). > > How exactly are name constraints going to make issuing such certs > easier or safer, and can you actually come up with a meaningful > name constraints for such a cert? > > -Martin This certificate has a whole bunch of SAN-dNSNames that are all over the DNS name space. So, no, there is no useful name constraint extension that the issuing cert(s) can have for this. Name constraints would be more useful if the Internet PKI was hierarchically constructed _with_ hierarchical authority of the name space. That would have been great, but it isn't the case (any CA that gets into the club can issue certs for any name). Maybe Nelson is thinking about an alternative Internet PKI or some private/enterprise PKI, where they could be useful. At this point, the best hope for a namespace-constrained Internet PKI might be with DNSSEC. I think there's a BOF on this topic at IETF next week. -- Shumon Huque University of Pennsylvania. From shuque@isc.upenn.edu Wed Jul 21 20:15:55 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 147003A6924 for ; Wed, 21 Jul 2010 20:15:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.537 X-Spam-Level: X-Spam-Status: No, score=-4.537 tagged_above=-999 required=5 tests=[AWL=-1.938, 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 LIDClKuUykGY for ; Wed, 21 Jul 2010 20:15:53 -0700 (PDT) Received: from talkeetna.isc-net.upenn.edu (TALKEETNA.isc-net.upenn.edu [128.91.197.188]) by core3.amsl.com (Postfix) with ESMTP id 814783A67F9 for ; Wed, 21 Jul 2010 20:15:53 -0700 (PDT) Received: by talkeetna.isc-net.upenn.edu (Postfix, from userid 4127) id 4B6762138; Wed, 21 Jul 2010 23:16:10 -0400 (EDT) Date: Wed, 21 Jul 2010 23:16:10 -0400 From: Shumon Huque To: =JeffH Message-ID: <20100722031610.GA5992@isc.upenn.edu> References: <4C4381D3.8010707@KingsMountain.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C4381D3.8010707@KingsMountain.com> User-Agent: Mutt/1.4.2.1i Organization: University of Pennsylvania Cc: IETF cert-based identity Subject: Re: [certid] Last Call: draft-saintandre-tls-server-id-check 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, 22 Jul 2010 03:15:55 -0000 On Sun, Jul 18, 2010 at 03:36:03PM -0700, =JeffH wrote: > hey folks, > > We're getting feedback on the ietf@ietf.org list wrt > draft-saintandre-tls-server-id-check. > > In particular, there's a question about the requirement to order the list > of reference identifiers in section "4.2. Constructing an Ordered List of > Reference Identifiers" that would be good to have implementors (in > particular) weigh in on. > > i.e. is the ordering requirement strictly necessary protocol-wise? Is it > (only) perhaps an implementation hint? > > thanks, > > =JeffH So, apart from the exchange Paul and I had on this topic on ietf@ietf, no-one else has expressed an opinion. So it looks like we're going in the direction of removing the requirement. -- Shumon Huque University of Pennsylvania. From peter.sylvester@edelweb.fr Thu Jul 22 02:14: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 6FFEA3A6A55 for ; Thu, 22 Jul 2010 02:14:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.185 X-Spam-Level: X-Spam-Status: No, score=-0.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185] 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 kjAAWSpVcrpk for ; Thu, 22 Jul 2010 02:14:57 -0700 (PDT) Received: from ganymede.on-x.com (ganymede.on-x.com [92.103.215.11]) by core3.amsl.com (Postfix) with ESMTP id 36D073A6A50 for ; Thu, 22 Jul 2010 02:14:34 -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 11A867D for ; Thu, 22 Jul 2010 11:14:50 +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 14B1E6ACE2 for ; Thu, 22 Jul 2010 11:14:50 +0200 (CEST) Received: from [192.168.0.7] (LPuteaux-156-14-17-14.w82-127.abo.wanadoo.fr [82.127.0.14]) by smtps.on-x.com (Postfix) with ESMTP id D87CE782B for ; Thu, 22 Jul 2010 11:14:49 +0200 (CEST) Message-ID: <4C480C06.9090805@edelweb.fr> Date: Thu, 22 Jul 2010 11:14:46 +0200 From: Peter Sylvester User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.10) Gecko/20100527 Thunderbird/3.0.5 MIME-Version: 1.0 To: certid@ietf.org References: <201007212312.o6LNCi8Y017372@fs4113.wdf.sap.corp> In-Reply-To: <201007212312.o6LNCi8Y017372@fs4113.wdf.sap.corp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [certid] Need to define "most specific RDN" 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, 22 Jul 2010 09:14:59 -0000 I am not sure that the discussion about constraints is the most pressing thing we need to talk about. ;-) Anyway, as Martin already summarized, the usage of common name to identify a server is deprecated since the last millenium. It is nncoding of a *complete* identifier as a subcomponent of another one, something that can happen for non technical purposes, e.g. user friendliness etc. Building software based on such ad hoc approaches requires pattern matching logic, etc, not very difficult to implement but not necessarily easy to use. In fact, I think that the whole of defining a thingy CN-ID complicates the whole text, it should just be a small note indicating that is is a particular encoding of exactly one DNS-ID. It seems to me that the changes in the last version already go into this direction. Nevertheless, the last paragraph of 2.2 (starting with "We recognize") introduces (AFAIR) a string representation of a DN which doesn't serve any real purpose and which has a strange "hierarchy". Note, that one explains that a DN in X.500 is a hierarchy. The implementation note refers to what? I see some confusion regarding the example. Just because we have mentioned all kinds of adjectives during the discussion, I do not see the value mentioning them. The only one that matters is the the "(most specific)" mentioned in RFC 2818 IMO. There are some people knowning X.500 quite well: If one respects the non-normative schema rules, can one have more than one Common Name AVA in a DN? It has also been said that using the reerm "representation" is unfortunate. In corresponding texts (X.500 etc), the word 'indication' is used. I suggest to change this all over in the document. /P From stpeter@stpeter.im Fri Jul 23 08:25: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 0CD583A692B; Fri, 23 Jul 2010 08:25:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.48 X-Spam-Level: X-Spam-Status: No, score=-2.48 tagged_above=-999 required=5 tests=[AWL=0.119, 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 b6k4mHdAJjsS; Fri, 23 Jul 2010 08:25:35 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 37DAC3A67E6; Fri, 23 Jul 2010 08:25:35 -0700 (PDT) Received: from squire.local (dsl-228-115.dynamic-dsl.frii.net [216.17.228.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id F31DD400EE; Fri, 23 Jul 2010 09:25:52 -0600 (MDT) Message-ID: <4C49B477.80700@stpeter.im> Date: Fri, 23 Jul 2010 09:25:43 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.11) Gecko/20100711 Thunderbird/3.0.6 MIME-Version: 1.0 To: ietf@ietf.org References: <20100715230822.5B1583A6B94@core3.amsl.com> In-Reply-To: <20100715230822.5B1583A6B94@core3.amsl.com> X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IETF cert-based identity Subject: Re: [certid] Last Call: draft-saintandre-tls-server-id-check (Representation and Verification of Domain-Based Application Service Identity in Certificates Used with Transport Layer Security) to Proposed Standard 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, 23 Jul 2010 15:25:36 -0000 Sorry, I haven't yet had a chance to review the feedback that's been provided during this Last Call. I'll do that en route to Maastricht today. Next week Jeff and I will discuss in person the points that have been raised, and then we'll post further regarding our proposed changes to the spec. Peter On 7/15/10 5:08 PM, The IESG wrote: > The IESG has received a request from an individual submitter to consider > the following document: > > - 'Representation and Verification of Domain-Based Application Service > Identity in Certificates Used with Transport Layer Security ' > as a Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2010-08-12. Exceptionally, > comments may be sent to iesg@ietf.org instead. In either case, please > retain the beginning of the Subject line to allow automated sorting. > > The file can be obtained via > http://www.ietf.org/internet-drafts/draft-saintandre-tls-server-id-check-08.txt > > > IESG discussion can be tracked via > https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=18634&rfc_flag=0 > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce From stpeter@stpeter.im Thu Jul 29 15:04:22 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 AAF753A67F4 for ; Thu, 29 Jul 2010 15:04:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 C8PDOCQofFjY for ; Thu, 29 Jul 2010 15:04:21 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id B812428C0D7 for ; Thu, 29 Jul 2010 15:04:21 -0700 (PDT) Received: by stpeter.im (Postfix, from userid 33) id 850ED40126; Thu, 29 Jul 2010 16:04:45 -0600 (MDT) Received: from 145.20.139.129 (SquirrelMail authenticated user stpeter) by stpeter.im with HTTP; Thu, 29 Jul 2010 16:04:45 -0600 (MDT) Message-ID: <62919.145.20.139.129.1280441085.squirrel@stpeter.im> Date: Thu, 29 Jul 2010 16:04:45 -0600 (MDT) From: "Peter Saint-Andre" To: certid@ietf.org User-Agent: SquirrelMail/1.4.8 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: [certid] action plan X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: stpeter@stpeter.im List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jul 2010 22:04:22 -0000 Based on feedback received on the lists and in person at IETF 78, Jeff and I will be meeting in Maastricht on Friday to determine what changes need to be made. We will then push out version -09 as soon as possible (I'm aiming for Saturday), after which we will ping all relevant lists and individuals to obtain further feedback so that this spec is as solid as we can make it. More soon. Peter -- Peter Saint-Andre https://stpeter.im/ From shuque@isc.upenn.edu Thu Jul 29 20:43: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 018C728C1BC; Thu, 29 Jul 2010 20:43:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.388 X-Spam-Level: X-Spam-Status: No, score=-4.388 tagged_above=-999 required=5 tests=[AWL=-1.789, 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 pM9lEt8zA1Vr; Thu, 29 Jul 2010 20:43:52 -0700 (PDT) Received: from talkeetna.isc-net.upenn.edu (TALKEETNA.isc-net.upenn.edu [128.91.197.188]) by core3.amsl.com (Postfix) with ESMTP id 8C79B28C1B8; Thu, 29 Jul 2010 20:43:52 -0700 (PDT) Received: by talkeetna.isc-net.upenn.edu (Postfix, from userid 4127) id 1DEF3242F; Thu, 29 Jul 2010 23:44:16 -0400 (EDT) Date: Thu, 29 Jul 2010 23:44:16 -0400 From: Shumon Huque To: Peter Saint-Andre Message-ID: <20100730034415.GA28022@isc.upenn.edu> References: <20100715230822.5B1583A6B94@core3.amsl.com> <4C49B477.80700@stpeter.im> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C49B477.80700@stpeter.im> User-Agent: Mutt/1.4.2.1i Organization: University of Pennsylvania Cc: IETF cert-based identity , ietf@ietf.org Subject: Re: [certid] Last Call: draft-saintandre-tls-server-id-check (Representation and Verification of Domain-Based Application Service Identity in Certificates Used with Transport Layer Security) to Proposed Standard 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, 30 Jul 2010 03:43:57 -0000 Peter, I'm not sure if this one is already on your list or not, but I didn't see it addressed in -08: I don't think the characterization of SRV-ID as an "indirect" (ie. DNS resolved) identifier is correct. Whether a subject name is indirect or not, depends on the content of the identifier field and how that content was obtained, rather than on the identifier type itself. In most cases, indirect identifiers will be found in DNS-ID or CN-ID, as a result of DNS resolution of SRV, CNAME, or other records. If an application is trying to authenticate such identities, then the document needs to clearly state under what conditions it is safe to do so (DNSSEC, or a static mapping rule in the client). The document does touch on safe derivation rules later (currently in 4.2). But the direct/indirect classification of identity types needs to be corrected (or just eliminated). I said some more here: http://www.ietf.org/mail-archive/web/certid/current/msg00220.html -- Shumon Huque University of Pennsylvania. On Fri, Jul 23, 2010 at 09:25:43AM -0600, Peter Saint-Andre wrote: > Sorry, I haven't yet had a chance to review the feedback that's been > provided during this Last Call. I'll do that en route to Maastricht > today. Next week Jeff and I will discuss in person the points that have > been raised, and then we'll post further regarding our proposed changes > to the spec. > > Peter > > On 7/15/10 5:08 PM, The IESG wrote: > > The IESG has received a request from an individual submitter to consider > > the following document: > > > > - 'Representation and Verification of Domain-Based Application Service > > Identity in Certificates Used with Transport Layer Security ' > > as a Proposed Standard > > > > The IESG plans to make a decision in the next few weeks, and solicits > > final comments on this action. Please send substantive comments to the > > ietf@ietf.org mailing lists by 2010-08-12. Exceptionally, > > comments may be sent to iesg@ietf.org instead. In either case, please > > retain the beginning of the Subject line to allow automated sorting. > > > > The file can be obtained via > > http://www.ietf.org/internet-drafts/draft-saintandre-tls-server-id-check-08.txt > > > > > > IESG discussion can be tracked via > > https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=18634&rfc_flag=0 > > > > _______________________________________________ > > IETF-Announce mailing list > > IETF-Announce@ietf.org > > https://www.ietf.org/mailman/listinfo/ietf-announce > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf -- Shumon Huque University of Pennsylvania. From peter.sylvester@edelweb.fr Thu Jul 29 22:50:58 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 51BCD3A6A79 for ; Thu, 29 Jul 2010 22:50:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.650, 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 Sbj8HMqHodQj for ; Thu, 29 Jul 2010 22:50:16 -0700 (PDT) Received: from ganymede.on-x.com (ganymede.on-x.com [92.103.215.11]) by core3.amsl.com (Postfix) with ESMTP id BAB0F3A6A72 for ; Thu, 29 Jul 2010 22:49:29 -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 EDA41148 for ; Fri, 30 Jul 2010 07:49:51 +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 B295F6CCC1 for ; Fri, 30 Jul 2010 07:49:51 +0200 (CEST) Received: from [192.168.0.12] (gut75-3-82-227-163-182.fbx.proxad.net [82.227.163.182]) by smtps.on-x.com (Postfix) with ESMTP id AD93D782B for ; Fri, 30 Jul 2010 07:49:51 +0200 (CEST) Message-ID: <4C5267FF.2090701@edelweb.fr> Date: Fri, 30 Jul 2010 07:49:51 +0200 From: Peter Sylvester User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.11) Gecko/20100713 Thunderbird/3.0.6 MIME-Version: 1.0 To: certid@ietf.org References: <20100715230822.5B1583A6B94@core3.amsl.com> <4C49B477.80700@stpeter.im> <20100730034415.GA28022@isc.upenn.edu> In-Reply-To: <20100730034415.GA28022@isc.upenn.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [certid] Last Call: draft-saintandre-tls-server-id-check (Representation and Verification of Domain-Based Application Service Identity in Certificates Used with Transport Layer Security) to Proposed Standard 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, 30 Jul 2010 05:50:58 -0000 On 07/30/2010 05:44 AM, Shumon Huque wrote: > But the > direct/indirect classification of identity types needs to be > corrected (or just eliminated). > +1 > I said some more here: > > http://www.ietf.org/mail-archive/web/certid/current/msg00220.html > > You seems to say there that the text basically nails down to two different id types, the dns based one (which is used in a very prominent uri using application, i.e. https), and URI-id types. It is a little bit difficult to have several certificates with different URI ids sharing the same ipaddress+port. tls servername indication has not provision for this. If one cannot have ids with different paths, what's the beef having a path in an identifier?. What also seems missing is a paragraph on what happens before the server presents its certificate, i.e. what means does have the client to direct the server, ip-address:port to connect and fqdn in the servername indication at least. ah, I forgot dtls? /P From shuque@isc.upenn.edu Fri Jul 30 09:20: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 393D43A6969 for ; Fri, 30 Jul 2010 09:20:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.26 X-Spam-Level: X-Spam-Status: No, score=-4.26 tagged_above=-999 required=5 tests=[AWL=-1.661, 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 Mymm7qLNYS2d for ; Fri, 30 Jul 2010 09:20:07 -0700 (PDT) Received: from talkeetna.isc-net.upenn.edu (TALKEETNA.isc-net.upenn.edu [128.91.197.188]) by core3.amsl.com (Postfix) with ESMTP id 2A62F3A6845 for ; Fri, 30 Jul 2010 09:20:07 -0700 (PDT) Received: by talkeetna.isc-net.upenn.edu (Postfix, from userid 4127) id C4C23241E; Fri, 30 Jul 2010 12:20:31 -0400 (EDT) Date: Fri, 30 Jul 2010 12:20:31 -0400 From: Shumon Huque To: Peter Sylvester Message-ID: <20100730162031.GA15319@isc.upenn.edu> References: <20100715230822.5B1583A6B94@core3.amsl.com> <4C49B477.80700@stpeter.im> <20100730034415.GA28022@isc.upenn.edu> <4C5267FF.2090701@edelweb.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C5267FF.2090701@edelweb.fr> User-Agent: Mutt/1.4.2.1i Organization: University of Pennsylvania Cc: certid@ietf.org Subject: Re: [certid] Last Call: draft-saintandre-tls-server-id-check (Representation and Verification of Domain-Based Application Service Identity in Certificates Used with Transport Layer Security) to Proposed Standard 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, 30 Jul 2010 16:20:08 -0000 On Fri, Jul 30, 2010 at 07:49:51AM +0200, Peter Sylvester wrote: > > You seems to say there that the text basically nails down to two > different id types, the dns based one (which is used in a very > prominent uri using application, i.e. https), and URI-id types. Well that, and SRVName. There are many other custom types defined by specific applications but those aren't the focus of this document. > It is a little bit difficult to have several certificates with > different URI ids sharing the same ipaddress+port. I agree .. > tls servername indication has not provision for this. Yeah, it's too bad the current SNI spec only supports "hostnames". Maybe we should look into updating that to support alternative name forms. > If one cannot have ids with different paths, what's the > beef having a path in an identifier?. One can't have them in SNI extensions (actually they can't even have URIs at all, with or without paths). But if they appear in a URI SAN, what should be done, as a general rule? That was my question. If we're intending to only focus on authenticating an application server rather than a specific resource located at that server, then it would be simpler to declare this topic out of scope. > What also seems missing is a paragraph on what > happens before the server presents its certificate, i.e. > what means does have the client to direct the server, > ip-address:port to connect and fqdn in the servername > indication at least. > > ah, I forgot dtls? I'm not sure that we have to deal with differences between DTLS and TLS. The certificate identity matching rules described in this document apply equally to both. The connection establishment details differ, but that's currently not a subject of this document. Do you disagree? -- Shumon Huque University of Pennsylvania. From prvs=58279e90b8=uri@ll.mit.edu Fri Jul 30 09:24:29 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 7B6433A68F2 for ; Fri, 30 Jul 2010 09:24:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.087 X-Spam-Level: X-Spam-Status: No, score=-6.087 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_OBFU_ALL=0.751, 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 1YTiQTORn89R for ; Fri, 30 Jul 2010 09:24:28 -0700 (PDT) Received: from mx1.ll.mit.edu (MX1.LL.MIT.EDU [129.55.12.45]) by core3.amsl.com (Postfix) with ESMTP id 2B31A3A6845 for ; Fri, 30 Jul 2010 09:24:28 -0700 (PDT) Received: from LLE2K7-HUB01.mitll.ad.local (LLE2K7-HUB01.mitll.ad.local) by mx1.ll.mit.edu (unknown) with ESMTP id o6UGOnj5008643 for ; Fri, 30 Jul 2010 12:24:49 -0400 From: "Blumenthal, Uri - 0668 - MITLL" To: "certid@ietf.org" Date: Fri, 30 Jul 2010 12:24:51 -0400 Thread-Topic: [certid] Last Call: draft-saintandre-tls-server-id-check (Representation and Verification of Domain-Based Application Service Identity in Certificates Used with Transport Layer Security) to Proposed Standard Thread-Index: AcswA7y/mPwh6YbQThKAKlLkLcMZ2w== Message-ID: References: <20100715230822.5B1583A6B94@core3.amsl.com> <4C49B477.80700@stpeter.im> <20100730034415.GA28022@isc.upenn.edu> <4C5267FF.2090701@edelweb.fr> <20100730162031.GA15319@isc.upenn.edu> In-Reply-To: <20100730162031.GA15319@isc.upenn.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.0.10011, 1.0.148, 0.0.0000 definitions=2010-07-30_04:2010-07-30, 2010-07-30, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-1005130000 definitions=main-1007300089 Subject: Re: [certid] Last Call: draft-saintandre-tls-server-id-check (Representation and Verification of Domain-Based Application Service Identity in Certificates Used with Transport Layer Security) to Proposed Standard 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, 30 Jul 2010 16:24:29 -0000 Certs (and issues related to them) probably is the one area where there sho= uld be absolutely no difference between TLS and DTLS, rule-wise. -- Regards, Uri uri@ll.mit.edu On Jul 30, 2010, at 12:20 PM, Shumon Huque wrote: > On Fri, Jul 30, 2010 at 07:49:51AM +0200, Peter Sylvester wrote: >>=20 >> You seems to say there that the text basically nails down to two >> different id types, the dns based one (which is used in a very >> prominent uri using application, i.e. https), and URI-id types. >=20 > Well that, and SRVName. There are many other custom types > defined by specific applications but those aren't the focus > of this document. >=20 >> It is a little bit difficult to have several certificates with >> different URI ids sharing the same ipaddress+port. >=20 > I agree .. >=20 >> tls servername indication has not provision for this. >=20 > Yeah, it's too bad the current SNI spec only supports "hostnames". > Maybe we should look into updating that to support alternative > name forms. >=20 >> If one cannot have ids with different paths, what's the >> beef having a path in an identifier?. >=20 > One can't have them in SNI extensions (actually they can't > even have URIs at all, with or without paths). But if they > appear in a URI SAN, what should be done, as a general rule? > That was my question. If we're intending to only focus on > authenticating an application server rather than a specific > resource located at that server, then it would be simpler > to declare this topic out of scope. >=20 >> What also seems missing is a paragraph on what >> happens before the server presents its certificate, i.e. >> what means does have the client to direct the server, >> ip-address:port to connect and fqdn in the servername >> indication at least. >>=20 >> ah, I forgot dtls? >=20 > I'm not sure that we have to deal with differences between=20 > DTLS and TLS. The certificate identity matching rules=20 > described in this document apply equally to both. The=20 > connection establishment details differ, but that's currently > not a subject of this document. Do you disagree? >=20 > --=20 > Shumon Huque > University of Pennsylvania. > _______________________________________________ > certid mailing list > certid@ietf.org > https://www.ietf.org/mailman/listinfo/certid From shuque@isc.upenn.edu Fri Jul 30 09:29:40 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 0C2F63A6A11 for ; Fri, 30 Jul 2010 09:29:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.774 X-Spam-Level: X-Spam-Status: No, score=-3.774 tagged_above=-999 required=5 tests=[AWL=-1.926, BAYES_00=-2.599, SARE_OBFU_ALL=0.751] 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 TGatGxKD6RNc for ; Fri, 30 Jul 2010 09:29:39 -0700 (PDT) Received: from talkeetna.isc-net.upenn.edu (TALKEETNA.isc-net.upenn.edu [128.91.197.188]) by core3.amsl.com (Postfix) with ESMTP id CB5923A6845 for ; Fri, 30 Jul 2010 09:29:38 -0700 (PDT) Received: by talkeetna.isc-net.upenn.edu (Postfix, from userid 4127) id ADB002466; Fri, 30 Jul 2010 12:30:03 -0400 (EDT) Date: Fri, 30 Jul 2010 12:30:03 -0400 From: Shumon Huque To: "Blumenthal, Uri - 0668 - MITLL" Message-ID: <20100730163003.GA15676@isc.upenn.edu> References: <20100715230822.5B1583A6B94@core3.amsl.com> <4C49B477.80700@stpeter.im> <20100730034415.GA28022@isc.upenn.edu> <4C5267FF.2090701@edelweb.fr> <20100730162031.GA15319@isc.upenn.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Organization: University of Pennsylvania Cc: "certid@ietf.org" Subject: Re: [certid] Last Call: draft-saintandre-tls-server-id-check (Representation and Verification of Domain-Based Application Service Identity in Certificates Used with Transport Layer Security) to Proposed Standard 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, 30 Jul 2010 16:29:40 -0000 Yup, agreed. I think that's what I tried to say. --Shumon. On Fri, Jul 30, 2010 at 12:24:51PM -0400, Blumenthal, Uri - 0668 - MITLL wrote: > Certs (and issues related to them) probably is the one area where there should be absolutely no difference between TLS and DTLS, rule-wise. > -- > Regards, > Uri uri@ll.mit.edu > > > > On Jul 30, 2010, at 12:20 PM, Shumon Huque wrote: > > > On Fri, Jul 30, 2010 at 07:49:51AM +0200, Peter Sylvester wrote: > >> > >> You seems to say there that the text basically nails down to two > >> different id types, the dns based one (which is used in a very > >> prominent uri using application, i.e. https), and URI-id types. > > > > Well that, and SRVName. There are many other custom types > > defined by specific applications but those aren't the focus > > of this document. > > > >> It is a little bit difficult to have several certificates with > >> different URI ids sharing the same ipaddress+port. > > > > I agree .. > > > >> tls servername indication has not provision for this. > > > > Yeah, it's too bad the current SNI spec only supports "hostnames". > > Maybe we should look into updating that to support alternative > > name forms. > > > >> If one cannot have ids with different paths, what's the > >> beef having a path in an identifier?. > > > > One can't have them in SNI extensions (actually they can't > > even have URIs at all, with or without paths). But if they > > appear in a URI SAN, what should be done, as a general rule? > > That was my question. If we're intending to only focus on > > authenticating an application server rather than a specific > > resource located at that server, then it would be simpler > > to declare this topic out of scope. > > > >> What also seems missing is a paragraph on what > >> happens before the server presents its certificate, i.e. > >> what means does have the client to direct the server, > >> ip-address:port to connect and fqdn in the servername > >> indication at least. > >> > >> ah, I forgot dtls? > > > > I'm not sure that we have to deal with differences between > > DTLS and TLS. The certificate identity matching rules > > described in this document apply equally to both. The > > connection establishment details differ, but that's currently > > not a subject of this document. Do you disagree? > > > > -- > > Shumon Huque > > University of Pennsylvania. > > _______________________________________________ > > certid mailing list > > certid@ietf.org > > https://www.ietf.org/mailman/listinfo/certid > > _______________________________________________ > certid mailing list > certid@ietf.org > https://www.ietf.org/mailman/listinfo/certid -- Shumon Huque University of Pennsylvania.