From stpeter@stpeter.im Fri Dec 3 09:27:14 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 A2FB228C11F for ; Fri, 3 Dec 2010 09:27:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.292 X-Spam-Level: X-Spam-Status: No, score=-102.292 tagged_above=-999 required=5 tests=[AWL=0.307, BAYES_00=-2.599, 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 TKtNhaxY08xg for ; Fri, 3 Dec 2010 09:27:13 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 069C928C0D0 for ; Fri, 3 Dec 2010 09:27:13 -0800 (PST) Received: from dhcp-64-101-72-234.cisco.com (dhcp-64-101-72-234.cisco.com [64.101.72.234]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 361044009B; Fri, 3 Dec 2010 10:39:55 -0700 (MST) Message-ID: <4CF928BD.9030004@stpeter.im> Date: Fri, 03 Dec 2010 10:28:29 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: Matt McCutchen References: <4CE47F39.4030401@stpeter.im> <4CF436F5.1030807@stpeter.im> <4CF437E1.2030703@stpeter.im> <1291087237.2571.4.camel@mattlaptop2.local> In-Reply-To: <1291087237.2571.4.camel@mattlaptop2.local> X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms060608090800090005080504" Cc: certid@ietf.org Subject: Re: [certid] version -11 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, 03 Dec 2010 17:27:14 -0000 This is a cryptographically signed message in MIME format. --------------ms060608090800090005080504 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 11/29/10 8:20 PM, Matt McCutchen wrote: > On Mon, 2010-11-29 at 16:31 -0700, Peter Saint-Andre wrote: >> Finally, although theoretically some consider the order of AVAs >> within an RDN to have meaning, in practice that rule is not observe= d. >> An AVA of type CN to be valid at any position within the subject >> field. >=20 > The last sentence is missing a verb. >=20 > Also, I don't see how AVAs within an RDN could ever have a meaningful > order. The RDN is a "SET OF" AVAs, i.e., unordered. The encoding orde= r > is not significant; in fact, it is fixed by DER. Right, my bad. It should be: Finally, although theoretically some consider the order of RDNs within a DN to have meaning, in practice that rule is not observed. An AVA of type CN is considered to be valid at any position within the subject field DN. --------------ms060608090800090005080504 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/ jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q 7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo 98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR 6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV 0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD 0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri 2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6 wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1 nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2 gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1 My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo 6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3 GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6 2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4 TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0 ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+ 39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c 6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2 0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0 H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0 dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTIw MzE3MjgyOVowIwYJKoZIhvcNAQkEMRYEFPVoNq3JC1cAWzraILcwVkHVKASzMF8GCSqGSIb3 DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG 9w0BAQEFAASCAQCgsa7SXDJPa5Q8yZsCNJ2ElqXeaa+64lvNEOUUsCFVUU5X2FKjmVxf7avd +LSmMyNGPEHOVQkoAii57IlrA1gIkrlaVWVVfGMRl7CjiOPCJkPPo/cM+/p+3k5aIpaclfiD Ex+PbgVoNLDV1/W82imuVycEtyux0fnAZW61wH+Sst5QmZBPFwF4tkb2zqNfux2DjsaRx04b Ps2M4E76vuFnZTQQs9rjSosG1mdtn3gys6sSwSsaQmOUqwqiPuo4oZq33aNsKH52bj2aBrqH yl9fSRvWcgag6n06J66lj+wlyqQQ06JDanyJ1jTcMoMJV5ZMqvUgoJILI6qOvrFKrXzKAAAA AAAA --------------ms060608090800090005080504-- From Peter.SaintAndre@webex.com Fri Dec 3 15:36:31 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FA143A659C; Fri, 3 Dec 2010 15:36:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.282 X-Spam-Level: X-Spam-Status: No, score=-103.282 tagged_above=-999 required=5 tests=[AWL=-1.050, BAYES_00=-2.599, MANGLED_LIST=2.3, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067, 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 pEEyEQzn2asv; Fri, 3 Dec 2010 15:36:30 -0800 (PST) Received: from gw1.webex.com (gw1.webex.com [64.68.122.208]) by core3.amsl.com (Postfix) with SMTP id 16FE828B56A; Fri, 3 Dec 2010 15:36:30 -0800 (PST) Received: from SRV-EXSC03.webex.local ([192.168.252.197]) by gw1.webex.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 3 Dec 2010 15:37:48 -0800 Received: from 64.101.74.200 ([64.101.74.200]) by SRV-EXSC03.webex.local ([192.168.252.200]) with Microsoft Exchange Server HTTP-DAV ; Fri, 3 Dec 2010 23:37:47 +0000 User-Agent: Microsoft-Entourage/12.12.0.080729 Date: Fri, 03 Dec 2010 16:37:47 -0700 From: Peter Saint-Andre To: Ben Campbell , Message-ID: Thread-Topic: Gen-ART LC Review of draft-saintandre-tls-server-id-check-11 Thread-Index: AcuTMJOBj1CKWFMWQP6PV1IpN2A9pQAEoOZ8 In-Reply-To: <92AA0A47-B3EE-4931-9203-92DB67946F3A@nostrum.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 03 Dec 2010 23:37:48.0304 (UTC) FILETIME=[17E31100:01CB9343] Cc: General Area Review Team , certid@ietf.org Subject: Re: [certid] Gen-ART LC Review of draft-saintandre-tls-server-id-check-11 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, 03 Dec 2010 23:36:31 -0000 Hi Ben, thanks for the review. [ + certid@ietf.org ] On 12/3/10 2:24 PM, "Ben Campbell" wrote: > I am the assigned Gen-ART reviewer for this draft. For background on > Gen-ART, please see the FAQ at > . >=20 > Please resolve these comments along with any other Last Call comments > you may receive. >=20 > Document: draft-saintandre-tls-server-id-check-11 > Reviewer: Ben Campbell > Review Date: 2010-12-03 > IETF LC End Date: 2010-12-16 >=20 > Summary: This draft is almost ready for publication as a BCP. I have a fe= w > questions and comments that I think should be considered first, as well a= s a > few editorial comments. >=20 > *** Major issues: >=20 > -- [ Not so much a "major issue" as a "slightly less minor" one] I'd like= to > see more discussion around URI-IDs. These seem to me to be the most compl= ex ID > type to get right, but there are no examples and limited discussion. Pick= ing > on SIP, purely as an example for which I have a passing familiarity: Woul= d a > SIP reference identity match a SIPS URI-ID in a certificate? Do I put bot= h a > URI-ID and an SRV-ID in my reference set and/or certificate? How do I ha= ndle > the fact that I sometimes need to do a NAPTR query, before the SRV query > depending on whether I know the transport protocol? (I realize SIP alread= y > defines cert ID matching, but what would I do for a new application proto= col > URI with similar properties?) >=20 > I wonder if the answer is that such things are scheme specific, and that = its > hard to say much about the generic handling of URI-IDs. If so, it might b= e > worth mentioning that, and maybe discuss what things the designer of a ne= w > scheme should keep in mind. I agree that we need to say more about URI-IDs. I also agree that the recommendations are probably more technology-specific than for other identifier types. Jeff and I will work on some text and reply further. BTW, are you aware of any technologies other than SIP that use URI-IDs? That's the only one I'm aware of. > *** Minor issues: >=20 > -- 1.2, last paragraph: >=20 > Nothing normative here? Do we think that protocol designers SHOULD refere= nce > document instead of rolling their own? For example, would you expect > additional IESG or SECDIR scrutiny for a new spec that rolls its own rath= er > than referenda this? As stated, this paragraph makes it sound like this i= s > something designers could use, rather than something designers should use= . It > seems like a BCP might take a stronger position. If two poor suckers go to the trouble of working up a BCP, I'd hope that folks would reference it when developing future protocols. But I don't thin= k putting a few MUSTs and SHOULDs in Section 1.2 is the way to make that happen. > -- 1.4.2, 2nd bullet item: "We also do not address identifiers derived fr= om > Naming Authority Pointer (NAPTR) DNS resource records [NAPTR] and related > technologies such as [S-NAPTR], since such identifiers cannot be validate= d in > a trusted manner in the absence of [DNSSEC]." >=20 > Does that mean validation of a source domain that will be used to constru= ct a > NAPTR request is out of scope, or just validation against the result of a > NAPTR query? (I note SIP may require the first). Another good question. Jeff and I need to research this a bit more before replying definitively. > -- 2.3, paragraph 1: >=20 > A DN example might be helpful. Never enough examples. :) We'll see about adding one here. > -- 2.3, paragraph 3: "application service is identified by a name or name= s > carried in the subject field and/or in one of the following identifier ty= pes" >=20 > May be identified, right? Since, as you mentioned earlier, it is common t= o > identify a service with a name plus service designator, and only the SRV-= ID > and URI-ID intrinsically do this. Fixed. > -- 3.1, rule 3: >=20 > What happens when you have multiple schemes that are defined to refer to = the > same resource. For example, SIP and SIPS? Does a SIP URI-ID match an > otherwise identical SIPS URI-ID? (Maybe this should be left to the URI > definitions themselves, but it might be worth mentioning the complication > somewhere.) Given that a user agent would not connect to sip:example.com or http://example.com/ via SSL/TLS, it seems appropriate for the certificate t= o include only the TLS-aware scheme (sips:, https:, etc.). > -- 3.1, rule 5: "... unless a profile of this specification... " >=20 > This pattern recurs throughout the document. Can you elaborate on what yo= u > mean by "profile"? Normally I think of a "profile" as defining a subset o= f > choices for some particular application. But if a profile relaxes a > requirement (i.e. encouraging something that is a SHOULD NOT here), that'= s not > really a subset. Are you referring to an application protocol spec that > refers to this document? Updates to this document? (I'm not sure if this > should count as a minor issue or an editorial comment. It depends on whet= her > its just a confusion around the word choice, or whether you have somethin= g > specific in mind that I did not grok). I think it's a terminological issue. By "profile" we mean "a specification that re-uses this one" -- as, say, draft-ietf-xmpp-3920bis re-uses this I-D= . The relationship is not one of defining a subset, but of being a downstream customer. Is there a good, single word for that? If not, I think we can say "Specifications that re-use this one" (ugly, but descriptive). > -- 3.1, rule 6: >=20 > Can you motivate why this is not a MUST NOT? Jeff has better numbers on this than I do, but a non-trivial number of existing certificates contain multiple CN-IDs. In addition, as long as control over the domain names has been certified then folks on the CertID list and other reviewers did not see harm in allowing CAs to include those domain names in CN-ID form, although it's not encouraged to do that. > -- section 3.2: >=20 > I'd like to see a (non-trivial) URL-ID example. Yes, we'll work to add that. > -- 3.2, first example: >=20 > Since we say you SHOULD NOT put the FQDN in a CN-ID, why include it in > examples? The example does seem to make sense, but it makes me wonder if = the > SHOULD NOT would be better placed on the client verification process not = the > cert generation process. I think it's better to delete that instance from the first example. > --4.2.1, paragraph 3: >=20 > It's probably out of scope, but it might be useful to offer some guidance= on > how ensuring the extraction is "not subject to subversion" is not always > trivial. For example, if you got your input URI by clicking on a link in = a > phishing email, that can be almost isomorphic to using a delegation from = a > non-trusted source. This is a matter of extracting the source domain from the input. Naturally the input itself might be compromised, but "garbage in, garbage out". I doubt this spec will prevent users from falling for phishing attacks. :) > -- 4.2.2: >=20 > Can we have a URI-ID example? (and maybe an explanation why the HTTP exam= ple > doesn't use one?) Yes, we'll add that, following RFC 5922 (although that doesn't have enough examples to borrow from). > -- 4.3, 4th bullet item: >=20 > An example would be helpful here. Yes, this goes along with the other URI-ID examples. > -- 4.4, rule 1: >=20 > Why not MUST NOT? Do you mean "why not MUST" (instead of SHOULD) for checking of the service type? > -- 5.1: >=20 > Should this doc mention anything about the ability to unpin? It's probably worth adding a sentence aobut that to the security note in Section 4.6.4. > *** Nits/editorial comments: >=20 > -- 1.1, paragraph 1: "...visible face of the Internet consists of service= s > that employ a client-server architecture..." >=20 > This seems a little overstated. Client-server applications are certainly > common, but they don't represent all common uses of the Internet. (Or do = I > misinterpret what you mean by "visible face"?) You're right, "largely consists" is more accurate. > "references some conception... of... identity" >=20 > I'm not sure what that means. Can you state this more plainly? Maybe "con= cept > of identity" or "idea of identity"? (I realize "conception" can mean > "concept", but it sounds strained to my mental ear.) How about "notion"? > -- 1.2, Paragraph 1: "document does not supersede the rules for certifica= te > issuance or validation provided in [PKIX]" >=20 > If this document does not supercede PKIX, then that also means that PKIX = is > authoritative on any point for which is draft may be in conflict with it, > right? Yes indeed. > "Specifically, in order to ensure proper authentication, application clie= nts > need to verify the entire certification path, because this document addre= sses > only name forms in the leaf server certificate, not any name forms in the > chain of certificates used to validate the server certificate." >=20 > Sentence hard to parse. Can it be broken up or simplified? I think this is better: This document does not supersede the rules for certificate issuance or validation provided in [PKIX]. Therefore, [PKIX] is authoritative on any point that might also be discussed in this document. Furthermore, [PKIX] also governs any certificate-related topic on which this document is silent, such as certificate syntax, certificate extensions such as name constraints and extended key usage, and handling of certification paths. This document addresses only name forms in the leaf server certificate, not any name forms in the chain of certificates used to validate the server certificate. Therefore, in order to ensure proper authentication, application clients need to verify the entire certification path. > -- 1.2, Paragraph 2: "existing application protocols" >=20 > Probably worth tying that to a point in time, as in "application protocol= s > that were specified prior to the publication of this BCP" Fixed. > -- 1.5, first paragraph: "each entry is preceded by a dollar sign ($) and= a > space." >=20 > I don't see any $'s Yes, that was an artifact of the editing process. Removed. > -- 1.5, definition of "delegated domain": "connecting to the source doma= in" >=20 > Is connecting to really the term you want here? Maybe "associated with"? = In > the context of this draft, I'm afraid people will think of connection in = terms > of tcp connections, etc. Changed to "communicating with" > -- 1.5, definition of "subject name" >=20 > Is there a definition or reference for "composite name"? Hmm, I don't see anything in RFC 5280, but I'll have to check the X.5** specs. > -- 1.6: >=20 > I don't know if it matters, but I usually see contributors and acknowledg= ments > sections near the end. It seems sort of abrupt to find them imbedded betw= een > technical content sections. This document was not the product of a WG so we probably wanted to show tha= t it has received wide-ranging reviews. I'm fine with moving that to the end. > -- 3.1, 1st paragraph: >=20 > It's probably worth emphasizing that the rules are often cumulative. I t= hink > someone thinking about these for the first time might not grasp that unti= l > they see examples later in the doc. I've added the second sentence to this paragraph: When a certification authority issues a certificate based on the fully-qualified DNS domain name at which the application service provider will provide the relevant application, the following rules apply to the representation of application service identities. The reader needs to be aware that some of these rules are cumulative and can interact in important ways that are illustrated later in this document. > -- 4.3, implementation note: "although such behavior is not forbidden by = this > document" >=20 > The "SHOULD stop the search" language in previous paragraph implies that = you > SHOULD NOT do this, doesn't it? So while it's not strictly forbidden, it'= s > strongly discouraged. The implementation note makes it sound more like it= is > merely out of scope. It's difference between: 1. Search for X and stop once you've found it. and 2. Search for X and stop once you've found it. Then search for Y. > -- 4.3, 4th bullet item >=20 > does the ABNF or URI reference define "reg-name" as well as "scheme"? Yes. In the URI spec, "reg-name" is an FQDN, not an IP address or mere host name. > That=20 > seems ambiguous. If not, then it might be helpful to have an expansion, > definition, or reference for "reg-name". Clarified as follows: o For a reference identifier of type URI-ID, the DNS domain name portion is the "reg-name" part of the "authority" component and the application type portion is the scheme name matching the [ABNF] "scheme" rule from [URI] (not including the ':' separator); note that this document specifies that a URI-ID always contains an "authority" component whose "host" subcomponent contains a "reg- name" (matching only the "reg-name" rule from [URI] limits verification to DNS domain names, differentiating a URI-ID from a uniformResourceIdentifier entry that contains an IP address or a mere host name, or that does not contain an "authority" component), and that extraction of the "reg-name" might necessitate normalization of the URI (as explained in [URI]). > -- 4.4: "Furthermore, if the client supports presented identifiers that > contain the wildcard character =B9*=B9, we define a supplemental rule for > so-called "wildcard certificates". >=20 > I think the definition will stay there regardless of the intent of the cl= ient > :-) Perhaps something to the effect of "... We define a supplemental > rule...which may be used by clients that support wildcards." Heh. Corrected to: Furthermore, to meet the needs of clients that support presented identifiers containing the wildcard character '*', we define a supplemental rule for so-called "wildcard certificates". Thanks again for your review. Jeff and I will confer regarding open issues and then reply further. Peter From paul.hoffman@vpnc.org Mon Dec 6 09:18:12 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 771F83A686D for ; Mon, 6 Dec 2010 09:18:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.746 X-Spam-Level: X-Spam-Status: No, score=-99.746 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, MANGLED_LIST=2.3, 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 WwY9tGGZf5jb for ; Mon, 6 Dec 2010 09:18:10 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 7B4303A681D for ; Mon, 6 Dec 2010 09:18:09 -0800 (PST) Received: from [10.20.30.151] (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 oB6HJWB5046333 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 6 Dec 2010 10:19:33 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Mon, 6 Dec 2010 09:19:30 -0800 To: certid@ietf.org From: Ben Campbell Content-Type: text/plain; charset="us-ascii" Subject: [certid] Gen-ART LC Review of draft-saintandre-tls-server-id-check-11 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, 06 Dec 2010 17:18:12 -0000 I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at . Please resolve these comments along with any other Last Call comments you may receive. Document: draft-saintandre-tls-server-id-check-11 Reviewer: Ben Campbell Review Date: 2010-12-03 IETF LC End Date: 2010-12-16 Summary: This draft is almost ready for publication as a BCP. I have a few questions and comments that I think should be considered first, as well as a few editorial comments. *** Major issues: -- [ Not so much a "major issue" as a "slightly less minor" one] I'd like to see more discussion around URI-IDs. These seem to me to be the most complex ID type to get right, but there are no examples and limited discussion. Picking on SIP, purely as an example for which I have a passing familiarity: Would a SIP reference identity match a SIPS URI-ID in a certificate? Do I put both a URI-ID and an SRV-ID in my reference set and/or certificate? How do I handle the fact that I sometimes need to do a NAPTR query, before the SRV query depending on whether I know the transport protocol? (I realize SIP already defines cert ID matching, but what would I do for a new application protocol URI with similar properties?) I wonder if the answer is that such things are scheme specific, and that its hard to say much about the generic handling of URI-IDs. If so, it might be worth mentioning that, and maybe discuss what things the designer of a new scheme should keep in mind. *** Minor issues: -- 1.2, last paragraph: Nothing normative here? Do we think that protocol designers SHOULD reference document instead of rolling their own? For example, would you expect additional IESG or SECDIR scrutiny for a new spec that rolls its own rather than referenda this? As stated, this paragraph makes it sound like this is something designers could use, rather than something designers should use. It seems like a BCP might take a stronger position. -- 1.4.2, 2nd bullet item: "We also do not address identifiers derived from Naming Authority Pointer (NAPTR) DNS resource records [NAPTR] and related technologies such as [S-NAPTR], since such identifiers cannot be validated in a trusted manner in the absence of [DNSSEC]." Does that mean validation of a source domain that will be used to construct a NAPTR request is out of scope, or just validation against the result of a NAPTR query? (I note SIP may require the first). -- 2.3, paragraph 1: A DN example might be helpful. -- 2.3, paragraph 3: "application service is identified by a name or names carried in the subject field and/or in one of the following identifier types" May be identified, right? Since, as you mentioned earlier, it is common to identify a service with a name plus service designator, and only the SRV-ID and URI-ID intrinsically do this. -- 3.1, rule 3: What happens when you have multiple schemes that are defined to refer to the same resource. For example, SIP and SIPS? Does a SIP URI-ID match an otherwise identical SIPS URI-ID? (Maybe this should be left to the URI definitions themselves, but it might be worth mentioning the complication somewhere.) -- 3.1, rule 5: "... unless a profile of this specification... " This pattern recurs throughout the document. Can you elaborate on what you mean by "profile"? Normally I think of a "profile" as defining a subset of choices for some particular application. But if a profile relaxes a requirement (i.e. encouraging something that is a SHOULD NOT here), that's not really a subset. Are you referring to an application protocol spec that refers to this document? Updates to this document? (I'm not sure if this should count as a minor issue or an editorial comment. It depends on whether its just a confusion around the word choice, or whether you have something specific in mind that I did not grok). -- 3.1, rule 6: Can you motivate why this is not a MUST NOT? -- section 3.2: I'd like to see a (non-trivial) URL-ID example. -- 3.2, first example: Since we say you SHOULD NOT put the FQDN in a CN-ID, why include it in examples? The example does seem to make sense, but it makes me wonder if the SHOULD NOT would be better placed on the client verification process not the cert generation process. --4.2.1, paragraph 3: It's probably out of scope, but it might be useful to offer some guidance on how ensuring the extraction is "not subject to subversion" is not always trivial. For example, if you got your input URI by clicking on a link in a phishing email, that can be almost isomorphic to using a delegation from a non-trusted source. -- 4.2.2: Can we have a URI-ID example? (and maybe an explanation why the HTTP example doesn't use one?) -- 4.3, 4th bullet item: An example would be helpful here. -- 4.4, rule 1: Why not MUST NOT? -- 5.1: Should this doc mention anything about the ability to unpin? *** Nits/editorial comments: -- 1.1, paragraph 1: "...visible face of the Internet consists of services that employ a client-server architecture..." This seems a little overstated. Client-server applications are certainly common, but they don't represent all common uses of the Internet. (Or do I misinterpret what you mean by "visible face"?) "references some conception... of... identity" I'm not sure what that means. Can you state this more plainly? Maybe "concept of identity" or "idea of identity"? (I realize "conception" can mean "concept", but it sounds strained to my mental ear.) -- 1.2, Paragraph 1: "document does not supersede the rules for certificate issuance or validation provided in [PKIX]" If this document does not supercede PKIX, then that also means that PKIX is authoritative on any point for which is draft may be in conflict with it, right? "Specifically, in order to ensure proper authentication, application clients need to verify the entire certification path, because this document addresses only name forms in the leaf server certificate, not any name forms in the chain of certificates used to validate the server certificate." Sentence hard to parse. Can it be broken up or simplified? -- 1.2, Paragraph 2: "existing application protocols" Probably worth tying that to a point in time, as in "application protocols that were specified prior to the publication of this BCP" -- 1.5, first paragraph: "each entry is preceded by a dollar sign ($) and a space." I don't see any $'s -- 1.5, definition of "delegated domain": "connecting to the source domain" Is connecting to really the term you want here? Maybe "associated with"? In the context of this draft, I'm afraid people will think of connection in terms of tcp connections, etc. -- 1.5, definition of "subject name" Is there a definition or reference for "composite name"? -- 1.6: I don't know if it matters, but I usually see contributors and acknowledgments sections near the end. It seems sort of abrupt to find them imbedded between technical content sections. -- 3.1, 1st paragraph: It's probably worth emphasizing that the rules are often cumulative. I think someone thinking about these for the first time might not grasp that until they see examples later in the doc. -- 4.3, implementation note: "although such behavior is not forbidden by this document" The "SHOULD stop the search" language in previous paragraph implies that you SHOULD NOT do this, doesn't it? So while it's not strictly forbidden, it's strongly discouraged. The implementation note makes it sound more like it is merely out of scope. -- 4.3, 4th bullet item does the ABNF or URI reference define "reg-name" as well as "scheme"? That seems ambiguous. If not, then it might be helpful to have an expansion, definition, or reference for "reg-name". -- 4.4: "Furthermore, if the client supports presented identifiers that contain the wildcard character '*', we define a supplemental rule for so-called "wildcard certificates". I think the definition will stay there regardless of the intent of the client :-) Perhaps something to the effect of "... We define a supplemental rule...which may be used by clients that support wildcards." From jwkckid1@ix.netcom.com Mon Dec 6 11:22: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 B14F33A68A9 for ; Mon, 6 Dec 2010 11:22:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.136 X-Spam-Level: X-Spam-Status: No, score=-0.136 tagged_above=-999 required=5 tests=[AWL=-1.696, BAYES_20=-0.74, MANGLED_LIST=2.3] 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 qWTjFTBDWBtM for ; Mon, 6 Dec 2010 11:22:25 -0800 (PST) Received: from elasmtp-galgo.atl.sa.earthlink.net (elasmtp-galgo.atl.sa.earthlink.net [209.86.89.61]) by core3.amsl.com (Postfix) with ESMTP id 057913A6895 for ; Mon, 6 Dec 2010 11:22:24 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=p4FjuLiYhS4vhsuTlUVjMqYG1qH7kcBxNz3E+VuTmblQu86F4AveRbH7ZIOqSsYq; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.24] (helo=mswamui-andean.atl.sa.earthlink.net) by elasmtp-galgo.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1PPgf6-0002L9-3p for certid@ietf.org; Mon, 06 Dec 2010 14:23:48 -0500 Received: from 99.93.224.206 by webmail.earthlink.net with HTTP; Mon, 6 Dec 2010 14:23:47 -0500 Message-ID: <847768.1291663427895.JavaMail.root@mswamui-andean.atl.sa.earthlink.net> Date: Mon, 6 Dec 2010 13:23:47 -0600 (GMT-06:00) From: "Jeffrey A. Williams" To: certid@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: c8e3929e1e9c87a874cfc7ce3b1ad11381c87f5e51960688123cedeb832206c151f088d9d782e492350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.24 Subject: Re: [certid] Gen-ART LC Review of draft-saintandre-tls-server-id-check-11 X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "Jeffrey A. Williams" List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Dec 2010 19:22:27 -0000 Ben and all, Very good questions all IMO. Thanks for asking them! >:) -----Original Message----- >From: Ben Campbell >Sent: Dec 6, 2010 11:19 AM >To: certid@ietf.org >Subject: [certid] Gen-ART LC Review of draft-saintandre-tls-server-id-check-11 > >I am the assigned Gen-ART reviewer for this draft. For background on >Gen-ART, please see the FAQ at >. > >Please resolve these comments along with any other Last Call comments >you may receive. > >Document: draft-saintandre-tls-server-id-check-11 >Reviewer: Ben Campbell >Review Date: 2010-12-03 >IETF LC End Date: 2010-12-16 > >Summary: This draft is almost ready for publication as a BCP. I have a few questions and comments that I think should be considered first, as well as a few editorial comments. > >*** Major issues: > >-- [ Not so much a "major issue" as a "slightly less minor" one] I'd like to see more discussion around URI-IDs. These seem to me to be the most complex ID type to get right, but there are no examples and limited discussion. Picking on SIP, purely as an example for which I have a passing familiarity: Would a SIP reference identity match a SIPS URI-ID in a certificate? Do I put both a URI-ID and an SRV-ID in my reference set and/or certificate? How do I handle the fact that I sometimes need to do a NAPTR query, before the SRV query depending on whether I know the transport protocol? (I realize SIP already defines cert ID matching, but what would I do for a new application protocol URI with similar properties?) > >I wonder if the answer is that such things are scheme specific, and that its hard to say much about the generic handling of URI-IDs. If so, it might be worth mentioning that, and maybe discuss what things the designer of a new scheme should keep in mind. > >*** Minor issues: > >-- 1.2, last paragraph: > >Nothing normative here? Do we think that protocol designers SHOULD reference document instead of rolling their own? For example, would you expect additional IESG or SECDIR scrutiny for a new spec that rolls its own rather than referenda this? As stated, this paragraph makes it sound like this is something designers could use, rather than something designers should use. It seems like a BCP might take a stronger position. > >-- 1.4.2, 2nd bullet item: "We also do not address identifiers derived from Naming Authority Pointer (NAPTR) DNS resource records [NAPTR] and related technologies such as [S-NAPTR], since such identifiers cannot be validated in a trusted manner in the absence of [DNSSEC]." > >Does that mean validation of a source domain that will be used to construct a NAPTR request is out of scope, or just validation against the result of a NAPTR query? (I note SIP may require the first). > > >-- 2.3, paragraph 1: > >A DN example might be helpful. > >-- 2.3, paragraph 3: "application service is identified by a name or names carried in the subject field and/or in one of the following identifier types" > >May be identified, right? Since, as you mentioned earlier, it is common to identify a service with a name plus service designator, and only the SRV-ID and URI-ID intrinsically do this. > >-- 3.1, rule 3: > >What happens when you have multiple schemes that are defined to refer to the same resource. For example, SIP and SIPS? Does a SIP URI-ID match an otherwise identical SIPS URI-ID? (Maybe this should be left to the URI definitions themselves, but it might be worth mentioning the complication somewhere.) > >-- 3.1, rule 5: "... unless a profile of this specification... " > >This pattern recurs throughout the document. Can you elaborate on what you mean by "profile"? Normally I think of a "profile" as defining a subset of choices for some particular application. But if a profile relaxes a requirement (i.e. encouraging something that is a SHOULD NOT here), that's not really a subset. Are you referring to an application protocol spec that refers to this document? Updates to this document? (I'm not sure if this should count as a minor issue or an editorial comment. It depends on whether its just a confusion around the word choice, or whether you have something specific in mind that I did not grok). > >-- 3.1, rule 6: > >Can you motivate why this is not a MUST NOT? > >-- section 3.2: > >I'd like to see a (non-trivial) URL-ID example. > >-- 3.2, first example: > >Since we say you SHOULD NOT put the FQDN in a CN-ID, why include it in examples? The example does seem to make sense, but it makes me wonder if the SHOULD NOT would be better placed on the client verification process not the cert generation process. > >--4.2.1, paragraph 3: > >It's probably out of scope, but it might be useful to offer some guidance on how ensuring the extraction is "not subject to subversion" is not always trivial. For example, if you got your input URI by clicking on a link in a phishing email, that can be almost isomorphic to using a delegation from a non-trusted source. > >-- 4.2.2: > >Can we have a URI-ID example? (and maybe an explanation why the HTTP example doesn't use one?) > >-- 4.3, 4th bullet item: > >An example would be helpful here. > >-- 4.4, rule 1: > >Why not MUST NOT? > >-- 5.1: > >Should this doc mention anything about the ability to unpin? > > >*** Nits/editorial comments: > >-- 1.1, paragraph 1: "...visible face of the Internet consists of services that employ a client-server architecture..." > >This seems a little overstated. Client-server applications are certainly common, but they don't represent all common uses of the Internet. (Or do I misinterpret what you mean by "visible face"?) > >"references some conception... of... identity" > >I'm not sure what that means. Can you state this more plainly? Maybe "concept of identity" or "idea of identity"? (I realize "conception" can mean "concept", but it sounds strained to my mental ear.) > > >-- 1.2, Paragraph 1: "document does not supersede the rules for certificate issuance or validation provided in [PKIX]" > >If this document does not supercede PKIX, then that also means that PKIX is authoritative on any point for which is draft may be in conflict with it, right? > >"Specifically, in order to ensure proper authentication, application clients need to verify the entire certification path, because this document addresses only name forms in the leaf server certificate, not any name forms in the chain of certificates used to validate the server certificate." > >Sentence hard to parse. Can it be broken up or simplified? > >-- 1.2, Paragraph 2: "existing application protocols" > >Probably worth tying that to a point in time, as in "application protocols that were specified prior to the publication of this BCP" > >-- 1.5, first paragraph: "each entry is preceded by a dollar sign ($) and a space." > >I don't see any $'s > >-- 1.5, definition of "delegated domain": "connecting to the source domain" > >Is connecting to really the term you want here? Maybe "associated with"? In the context of this draft, I'm afraid people will think of connection in terms of tcp connections, etc. > >-- 1.5, definition of "subject name" > >Is there a definition or reference for "composite name"? > >-- 1.6: > >I don't know if it matters, but I usually see contributors and acknowledgments sections near the end. It seems sort of abrupt to find them imbedded between technical content sections. > >-- 3.1, 1st paragraph: > >It's probably worth emphasizing that the rules are often cumulative. I think someone thinking about these for the first time might not grasp that until they see examples later in the doc. > >-- 4.3, implementation note: "although such behavior is not forbidden by this document" > >The "SHOULD stop the search" language in previous paragraph implies that you SHOULD NOT do this, doesn't it? So while it's not strictly forbidden, it's strongly discouraged. The implementation note makes it sound more like it is merely out of scope. > >-- 4.3, 4th bullet item > >does the ABNF or URI reference define "reg-name" as well as "scheme"? That seems ambiguous. If not, then it might be helpful to have an expansion, definition, or reference for "reg-name". > >-- 4.4: "Furthermore, if the client supports presented identifiers that contain the wildcard character '*', we define a supplemental rule for so-called "wildcard certificates". > >I think the definition will stay there regardless of the intent of the client :-) Perhaps something to the effect of "... We define a supplemental rule...which may be used by clients that support wildcards." >_______________________________________________ >certid mailing list >certid@ietf.org >https://www.ietf.org/mailman/listinfo/certid Regards, Jeffrey A. Williams "Obedience of the law is the greatest freedom" - Abraham Lincoln "Credit should go with the performance of duty and not with what is very often the accident of glory" - Theodore Roosevelt "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 Network Eng. SR. Eng. Network data security ABA member in good standing member ID 01257402 E-Mail jwkckid1@ix.netcom.com Phone: 214-244-4827 From Jeff.Hodges@KingsMountain.com Mon Dec 6 16:59:14 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 81E5C28C0E7 for ; Mon, 6 Dec 2010 16:59:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.257 X-Spam-Level: X-Spam-Status: No, score=-100.257 tagged_above=-999 required=5 tests=[AWL=-0.292, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, MANGLED_LIST=2.3, 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 C2CQ33enrK+W for ; Mon, 6 Dec 2010 16:59:13 -0800 (PST) Received: from cpoproxy1-pub.bluehost.com (cpoproxy1-pub.bluehost.com [69.89.21.11]) by core3.amsl.com (Postfix) with SMTP id E632828C0DB for ; Mon, 6 Dec 2010 16:59:12 -0800 (PST) Received: (qmail 14833 invoked by uid 0); 7 Dec 2010 01:00:37 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by cpoproxy1.bluehost.com with SMTP; 7 Dec 2010 01:00:37 -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:CC:Subject:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=ndgdxp8ma4GZW8innjXh/pDYiXormq3sNls+E5NyUkWoVZgZ5rDDXPJ3Y29cJiE7qfadpv8VIzxr43MnqHKSsFHZKuvREqetRNxazMTUdgke0cBPSfkAmBAOTd+8JAPj; 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 1PPlv2-0004hE-Ia; Mon, 06 Dec 2010 18:00:36 -0700 Message-ID: <4CFD8731.9060208@KingsMountain.com> Date: Mon, 06 Dec 2010 17:00:33 -0800 From: =JeffH User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: Ben Campbell , Peter Saint-Andre 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} Cc: draft-saintandre-tls-server-id-check.all@tools.ietf.org, General Area Review Team , IETF cert-based identity Subject: Re: [certid] Gen-ART LC Review of draft-saintandre-tls-server-id-check-11 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, 07 Dec 2010 00:59:14 -0000 a followup on aspects of PeterSA's response.. Peter Saint-Andre replied.. > > On 12/3/10 2:24 PM, "Ben Campbell" wrote: > thanks for the review. >> -- 3.1, rule 3: >> >> What happens when you have multiple schemes that are defined to refer= to >> the same resource. For example, SIP and SIPS? Does a SIP URI-ID matc= h an >> otherwise identical SIPS URI-ID? (Maybe this should be left to the UR= I >> definitions themselves, but it might be worth mentioning the complica= tion >> somewhere.) > > Given that a user agent would not connect to sip:example.com or > http://example.com/ via SSL/TLS, it seems appropriate for the certific= ate to > include only the TLS-aware scheme (sips:, https:, etc.). Yes, the latter seems appropriate, however RFC 5922 "Domain Certificates = in the=20 Session Initiation Protocol (SIP)" seems to be ambiguous (or maybe broken= ) on=20 this point. Eg [S7.1] of RFC 5922 says in part.. 1. Examine each value in the subjectAltName field. ... Each value in the subjectAltName has a type; the only types acceptable= for encoding a SIP domain identity SHALL be: URI If the scheme of the URI is not "sip", then the implementation MUST NOT accept the value as a SIP domain identity. ... DNS An implementation MUST accept a domain name system identifier as a SIP domain identity if and only if no other= identity is found that matches the "sip" URI type described= above. The above is saying that "sip:example.com" is what ought to be found as a= =20 subjectAltName:uniformResourceIdentifier value -- note that it says that = one=20 MUST NOT accept the cert if the URI scheme isn't "sip". Also, RFC 5626 "Client-Initiated Connections in SIP" notes in [S4.3].. ... For TLS protocols, there MUST also= be a match between the host production in the next hop and one of the= URIs contained in the subjectAltName in the peer certificate. ... =2E.but doesn't say anything about the URI scheme. And RFC 5630 "The Use of the SIPS URI Scheme in the Session Initiation Pr= otocol=20 (SIP)" appears to not say anything about certificate validation or name=20 matching (it appears to punt to RFC 5626). Finally, RFC 3261 -- the base SIP spec -- appears to only really discuss = S/MIME=20 certs. Are there other SIP RFCs we should also peruse? >> -- 3.1, rule 5: "... unless a profile of this specification... " >> >> This pattern recurs throughout the document. Can you elaborate on wha= t you >> mean by "profile"? Normally I think of a "profile" as defining a sub= set >> of choices for some particular application. But if a profile relaxes = a >> requirement (i.e. encouraging something that is a SHOULD NOT here), t= hat's >> not really a subset. Are you referring to an application protocol sp= ec >> that refers to this document? Updates to this document? (I'm not sure= if >> this should count as a minor issue or an editorial comment. It depend= s on >> whether its just a confusion around the word choice, or whether you h= ave >> something specific in mind that I did not grok). > > I think it's a terminological issue. By "profile" we mean "a specifica= tion > that re-uses this one" -- as, say, draft-ietf-xmpp-3920bis re-uses thi= s I-D. > The relationship is not one of defining a subset, but of being a down= stream > customer. Is there a good, single word for that? If not, I think we c= an say > "Specifications that re-use this one" (ugly, but descriptive). how about "normatively reference" rather than "re-use" ? >> -- 3.1, rule 6: >> >> Can you motivate why this is not a MUST NOT? > > Jeff has better numbers on this than I do, but a non-trivial number of= > existing certificates contain multiple CN-IDs. In addition, as long as= > control over the domain names has been certified then folks on the Cer= tID > list and other reviewers did not see harm in allowing CAs to include t= hose > domain names in CN-ID form, although it's not encouraged to do that. Rule 6 is.. 6. The certificate MAY contain more than one DNS-ID, SRV-ID, or URI-ID (but SHOULD NOT contain more than one CN-ID). The reason for allowing this wiggle-room is that (for better or worse).. 1. the CA/Browser Forum Extended Validation (EV) Certificate Guideline= s explicitly allow for multiple CN-IDs 2. It's a not-totally-uncommon current practice to have certs that do = have mutiple CN-IDs, eg from Comodo (whether EV or DV (domain valivdated= )). 3. Virtual hosting multiple distinct-domain TLS servers on one entity = is difficult today if one desires wide desktop client support because a certain vendor's older-but-still-widely-deployed-OS does not (yet= ?) support the TLS Server Name Indication extension. Thus having one cert with all the domains jammed in it (as either/both CN-IDs or/an= d DNS-IDs) is a workaround (eg Content Delivery Networks use this). So some argue that if we MUST NOT multiple CN-IDs at this point, it is fl= ying=20 in the face of present reality and might contribute to acquiring an attai= ned=20 reputation for this BCP that is lower than we desire. There is also concern on the part of CA folk about client-side TLS libs a= nd=20 their support for name matching (ie some (old?) one(s) will only match on= CN-ID). For a CA perspective on all the above, see... Re: [certid] weird CN-IDs (subjectCommonName) in SSL Labs Survey Data http://www.ietf.org/mail-archive/web/certid/current/msg00502.html >> -- 3.2, first example: >> >> Since we say you SHOULD NOT put the FQDN in a CN-ID, why include it i= n >> examples? The example does seem to make sense, but it makes me wonder= if >> the SHOULD NOT would be better placed on the client verification proc= ess >> not the cert generation process. > > I think it's better to delete that instance from the first example. agreed. >> *** Nits/editorial comments: >> >> -- 1.1, paragraph 1: "...visible face of the Internet consists of ser= vices >> that employ a client-server architecture..." >> >> This seems a little overstated. Client-server applications are certai= nly >> common, but they don't represent all common uses of the Internet. (Or= do I >> misinterpret what you mean by "visible face"?) > > You're right, "largely consists" is more accurate. agreed. >> "references some conception... of... identity" >> >> I'm not sure what that means. Can you state this more plainly? Maybe >> "concept of identity" or "idea of identity"? (I realize "conception" = can >> mean "concept", but it sounds strained to my mental ear.) > > How about "notion"? "notion" sounds fine to me. >> -- 1.2, Paragraph 1: "document does not supersede the rules for >> certificate issuance or validation provided in [PKIX]" >> >> If this document does not supercede PKIX, then that also means that P= KIX >> is authoritative on any point for which is draft may be in conflict w= ith >> it, right? > > Yes indeed. > >> "Specifically, in order to ensure proper authentication, application >> clients need to verify the entire certification path, because this >> document addresses only name forms in the leaf server certificate, no= t any >> name forms in the chain of certificates used to validate the server >> certificate." >> >> Sentence hard to parse. Can it be broken up or simplified? > > I think this is better: > > This document does not supersede the rules for certificate issuance or= > validation provided in [PKIX]. Therefore, [PKIX] is authoritative on = any > point that might also be discussed in this document. Furthermore, [PKI= X] > also governs any certificate-related topic on which this document is s= ilent, > such as certificate syntax, certificate extensions such as name constr= aints > and extended key usage, and handling of certification paths. > > This document addresses only name forms in the leaf server certificate= , not > any name forms in the chain of certificates used to validate the serve= r > certificate. Therefore, in order to ensure proper authentication, > application clients need to verify the entire certification path. looks good to me (LGTM) >> -- 1.5, definition of "subject name" >> >> Is there a definition or reference for "composite name"? > > Hmm, I don't see anything in RFC 5280, but I'll have to check the X.5*= * > specs. "composite name" doesn't appear in the X.5?? specs AFAICT. how about simply s/composite name/name/ ? >> -- 3.1, 1st paragraph: >> >> It's probably worth emphasizing that the rules are often cumulative. = I >> think someone thinking about these for the first time might not grasp= that >> until they see examples later in the doc. > > I've added the second sentence to this paragraph: > > When a certification authority issues a certificate based on the > fully-qualified DNS domain name at which the application service provi= der > will provide the relevant application, the following rules apply to th= e > representation of application service identities. The reader needs to= be > aware that some of these rules are cumulative and can interact in impo= rtant > ways that are illustrated later in this document. LGTM. >> -- 4.3, 4th bullet item >> >> does the ABNF or URI reference define "reg-name" as well as "scheme"?= > > Yes. In the URI spec, "reg-name" is an FQDN, not an IP address or mere= host > name. > >> That seems ambiguous. If not, then it might be helpful to have an >> expansion, definition, or reference for "reg-name". > > Clarified as follows: > > o For a reference identifier of type URI-ID, the DNS domain name port= ion is > the "reg-name" part of the "authority" component and the application t= ype > portion is the scheme name matching the [ABNF] "scheme" rule from [URI= ] (not > including the ':' separator); note that this document specifies that a= > URI-ID always contains an "authority" component whose "host" subcompon= ent > contains a "reg- name" (matching only the "reg-name" rule from [URI] l= imits > verification to DNS domain names, differentiating a URI-ID from a > uniformResourceIdentifier entry that contains an IP address or a mere = host > name, or that does not contain an "authority" component), and that > extraction of the "reg-name" might necessitate normalization of the UR= I (as > explained in [URI]). LGTM. >> -- 4.4: "Furthermore, if the client supports presented identifiers t= hat >> contain the wildcard character =B9*=B9, we define a supplemental rule= for >> so-called "wildcard certificates". >> >> I think the definition will stay there regardless of the intent of th= e >> client :-) Perhaps something to the effect of "... We define a >> supplemental rule...which may be used by clients that support wildcar= ds." > > Heh. Corrected to: > > Furthermore, to meet the needs of clients that support presented ident= ifiers > containing the wildcard character '*', we define a supplemental rule f= or > so-called "wildcard certificates". LGTM. thx again for your review, =3DJeffH From Jeff.Hodges@KingsMountain.com Mon Dec 6 17:04: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 76A773A68DE for ; Mon, 6 Dec 2010 17:04:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.922 X-Spam-Level: X-Spam-Status: No, score=-99.922 tagged_above=-999 required=5 tests=[AWL=-0.393, BAYES_20=-0.74, IP_NOT_FRIENDLY=0.334, RCVD_IN_SORBS_DUL=0.877, 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 uItrxp7cIDKD for ; Mon, 6 Dec 2010 17:04:35 -0800 (PST) Received: from oproxy2-pub.bluehost.com (oproxy2-pub.bluehost.com [67.222.39.60]) by core3.amsl.com (Postfix) with SMTP id 661903A68DA for ; Mon, 6 Dec 2010 17:04:35 -0800 (PST) Received: (qmail 2028 invoked by uid 0); 7 Dec 2010 01:05:59 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy2.bluehost.com with SMTP; 7 Dec 2010 01:05:59 -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=Y0PdXHY488ATcpyapFD7ekuddi7PEU9a+iFoWZTbIVM9pgTGwgNS/YvdOzVD+SgNY80E8ZHEiYiSIo2sIVRNAJgJfg1dVKSB4F2bHkt4I5e/OfTkTJEUuMLU3kLEU2l2; 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 1PPm0F-0001ds-A8 for certid@ietf.org; Mon, 06 Dec 2010 18:05:59 -0700 Message-ID: <4CFD8875.30107@KingsMountain.com> Date: Mon, 06 Dec 2010 17:05:57 -0800 From: =JeffH User-Agent: Thunderbird 2.0.0.24 (X11/20101027) 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] EFF (TLS/)SSL Observatory data available 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, 07 Dec 2010 01:04:37 -0000 The EFF (TLS/)SSL Observatory data is available via links to .torrent files here.. https://www.eff.org/observatory the 3 files all together take ~13gb of space compressed. I haven't yet poked through them so don't know what it'll be when unpacked. =JeffH From stpeter@stpeter.im Mon Dec 6 20:09: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 4B24828C0EA; Mon, 6 Dec 2010 20:09:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.724 X-Spam-Level: X-Spam-Status: No, score=-102.724 tagged_above=-999 required=5 tests=[AWL=-0.125, BAYES_00=-2.599, 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 enOOwh9QRDy8; Mon, 6 Dec 2010 20:09:33 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 8FFBA28C0CF; Mon, 6 Dec 2010 20:09:33 -0800 (PST) Received: from squire.local (ip-216-17-182-51.rev.frii.com [216.17.182.51]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 858714009B; Mon, 6 Dec 2010 21:22:40 -0700 (MST) Message-ID: <4CFDB3CF.60507@stpeter.im> Date: Mon, 06 Dec 2010 21:10:55 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: =JeffH References: <4CFD8731.9060208@KingsMountain.com> In-Reply-To: <4CFD8731.9060208@KingsMountain.com> X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms040707030203030801000603" Cc: Ben Campbell , General Area Review Team , IETF cert-based identity , draft-saintandre-tls-server-id-check.all@tools.ietf.org Subject: Re: [certid] Gen-ART LC Review of draft-saintandre-tls-server-id-check-11 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, 07 Dec 2010 04:09:35 -0000 This is a cryptographically signed message in MIME format. --------------ms040707030203030801000603 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 12/6/10 6:00 PM, =3DJeffH wrote: > a followup on aspects of PeterSA's response.. Thanks, Jeff. A few comments inline from your co-author. :) > Peter Saint-Andre replied.. >> >> On 12/3/10 2:24 PM, "Ben Campbell" wrote: >> >=20 > thanks for the review. >=20 >=20 >>> -- 3.1, rule 3: >>> >>> What happens when you have multiple schemes that are defined to refer= to >>> the same resource. For example, SIP and SIPS? Does a SIP URI-ID > match an >>> otherwise identical SIPS URI-ID? (Maybe this should be left to the UR= I >>> definitions themselves, but it might be worth mentioning the > complication >>> somewhere.) >> >> Given that a user agent would not connect to sip:example.com or >> http://example.com/ via SSL/TLS, it seems appropriate for the > certificate to >> include only the TLS-aware scheme (sips:, https:, etc.). >=20 > Yes, the latter seems appropriate, however RFC 5922 "Domain Certificate= s > in the Session Initiation Protocol (SIP)" seems to be ambiguous (or > maybe broken) on this point. Eg [S7.1] of RFC 5922 says in part.. >=20 > 1. Examine each value in the subjectAltName field. ... Each > value in the subjectAltName has a type; the only types acceptabl= e > for encoding a SIP domain identity SHALL be: >=20 > URI If the scheme of the URI is not "sip", then the > implementation MUST NOT accept the value as a SIP domain > identity. >=20 > ... >=20 > DNS An implementation MUST accept a domain name system > identifier as a SIP domain identity if and only if no othe= r > identity is found that matches the "sip" URI type describe= d > above. >=20 >=20 > The above is saying that "sip:example.com" is what ought to be found as= > a subjectAltName:uniformResourceIdentifier value -- note that it says > that one MUST NOT accept the cert if the URI scheme isn't "sip". Yes, that seems strange -- why not "sips"? > Also, RFC 5626 "Client-Initiated Connections in SIP" > notes in [S4.3].. >=20 > ... For TLS protocols, there MUST als= o > be a match between the host production in the next hop and one of th= e > URIs contained in the subjectAltName in the peer certificate. ... >=20 > ..but doesn't say anything about the URI scheme. >=20 > And RFC 5630 "The Use of the SIPS URI Scheme in the Session Initiation > Protocol (SIP)" appears to not say anything about certificate validatio= n > or name matching (it appears to punt to RFC 5626). >=20 > Finally, RFC 3261 -- the base SIP spec -- appears to only really discus= s > S/MIME certs. >=20 > Are there other SIP RFCs we should also peruse? That seems to be the right set of documents. We just need to figure out how to interpret them. Not that our I-D needs to legislate for the SIP community (but it would be nice if that community could re-use our I-D in the future if desired). >>> -- 3.1, rule 5: "... unless a profile of this specification... " >>> >>> This pattern recurs throughout the document. Can you elaborate on > what you >>> mean by "profile"? Normally I think of a "profile" as defining a sub= set >>> of choices for some particular application. But if a profile relaxes = a >>> requirement (i.e. encouraging something that is a SHOULD NOT here), > that's >>> not really a subset. Are you referring to an application protocol sp= ec >>> that refers to this document? Updates to this document? (I'm not sure= if >>> this should count as a minor issue or an editorial comment. It > depends on >>> whether its just a confusion around the word choice, or whether you h= ave >>> something specific in mind that I did not grok). >> >> I think it's a terminological issue. By "profile" we mean "a > specification >> that re-uses this one" -- as, say, draft-ietf-xmpp-3920bis re-uses > this I-D. >> The relationship is not one of defining a subset, but of being a > downstream >> customer. Is there a good, single word for that? If not, I think we > can say >> "Specifications that re-use this one" (ugly, but descriptive). >=20 > how about "normatively reference" rather than "re-use" ? I keep thinking that it's possible to normatively reference this spec without re-using its rules -- perhaps someone likes our terminology and normatively references the spec for our definitions of "source domain" and "derived domain". >>> -- 3.1, rule 6: >>> >>> Can you motivate why this is not a MUST NOT? >> >> Jeff has better numbers on this than I do, but a non-trivial number of= >> existing certificates contain multiple CN-IDs. In addition, as long as= >> control over the domain names has been certified then folks on the Cer= tID >> list and other reviewers did not see harm in allowing CAs to include > those >> domain names in CN-ID form, although it's not encouraged to do that. >=20 >=20 > Rule 6 is.. >=20 > 6. The certificate MAY contain more than one DNS-ID, SRV-ID, or > URI-ID (but SHOULD NOT contain more than one CN-ID). >=20 >=20 > The reason for allowing this wiggle-room is that (for better or worse).= =2E >=20 > 1. the CA/Browser Forum Extended Validation (EV) Certificate Guidelin= es > explicitly allow for multiple CN-IDs >=20 > 2. It's a not-totally-uncommon current practice to have certs that do= > have > mutiple CN-IDs, eg from Comodo (whether EV or DV (domain valivdate= d)). >=20 > 3. Virtual hosting multiple distinct-domain TLS servers on one entity= is > difficult today if one desires wide desktop client support because= > a certain vendor's older-but-still-widely-deployed-OS does not (ye= t?) > support the TLS Server Name Indication extension. Thus having one > cert with all the domains jammed in it (as either/both CN-IDs or/a= nd > DNS-IDs) is a workaround (eg Content Delivery Networks use this). >=20 >=20 > So some argue that if we MUST NOT multiple CN-IDs at this point, it is > flying in the face of present reality and might contribute to acquiring= > an attained reputation for this BCP that is lower than we desire. >=20 > There is also concern on the part of CA folk about client-side TLS libs= > and their support for name matching (ie some (old?) one(s) will only > match on CN-ID). >=20 > For a CA perspective on all the above, see... >=20 > Re: [certid] weird CN-IDs (subjectCommonName) in SSL Labs Survey Data > http://www.ietf.org/mail-archive/web/certid/current/msg00502.html +1 to all that. >>> -- 1.5, definition of "subject name" >>> >>> Is there a definition or reference for "composite name"? >> >> Hmm, I don't see anything in RFC 5280, but I'll have to check the X.5*= * >> specs. >=20 > "composite name" doesn't appear in the X.5?? specs AFAICT. >=20 > how about simply s/composite name/name/ ? Sure. I got "composite name" from you and I thought perhaps it was some sacred term from the X.5** series. :) Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms040707030203030801000603 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/ jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q 7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo 98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR 6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV 0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD 0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri 2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6 wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1 nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2 gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1 My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo 6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3 GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6 2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4 TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0 ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+ 39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c 6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2 0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0 H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0 dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTIw NzA0MTA1NVowIwYJKoZIhvcNAQkEMRYEFESwGvo8AvlYTi/39J2tuh61iydoMF8GCSqGSIb3 DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG 9w0BAQEFAASCAQB2oZIf08ZGhM5GPcpSR82i0tMmv+SFy+fNk3TmXAn3vsz2bpk7m2bugaeI ftW/v0uWRQ1LdwqOszGapq8yLlGWwZ33ZQ/3Mi/kWIfpa+f8H03jAElqW7mNhBAcRuG5BH+j UI96vytypi/2DfMYCn0Bx80l/ocPKuMJr/VT9M3yse0xDIf/D/SuDD1zBuH8kcWlXOQXDAlP TBUeF5ZLaqlrgSryTwg4YIRJmpg8O5MoazRBfc1HpZ93VSKEL8N5PsDIaYIPXUhWyqEKh+ak pkik9W/tYMGD9iW8LZ2wwXvgTM8NeIEQCdMnvekX2eW35f4Pltc2+hpmfy9L7SScFAUDAAAA AAAA --------------ms040707030203030801000603-- From paul.hoffman@vpnc.org Tue Dec 7 06:59: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 AECC43A6818; Tue, 7 Dec 2010 06:59:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.4 X-Spam-Level: X-Spam-Status: No, score=-101.4 tagged_above=-999 required=5 tests=[AWL=0.646, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 30dqmQM0a5lQ; Tue, 7 Dec 2010 06:59:39 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id DF9E43A67A7; Tue, 7 Dec 2010 06:59:39 -0800 (PST) Received: from [10.20.30.150] (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 oB7F11H9009121 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 7 Dec 2010 08:01:03 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <4CFDB3CF.60507@stpeter.im> References: <4CFD8731.9060208@KingsMountain.com> <4CFDB3CF.60507@stpeter.im> Date: Tue, 7 Dec 2010 07:01:00 -0800 To: Peter Saint-Andre , =JeffH From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: Ben Campbell , General Area Review Team , IETF cert-based identity , draft-saintandre-tls-server-id-check.all@tools.ietf.org Subject: Re: [certid] Gen-ART LC Review of draft-saintandre-tls-server-id-check-11 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, 07 Dec 2010 14:59:40 -0000 [[ Much abbreviated ]] At 9:10 PM -0700 12/6/10, Peter Saint-Andre wrote: > >>> -- 3.1, rule 6: >>>> > >>> Can you motivate why this is not a MUST NOT? > > The reason for allowing this wiggle-room is that (for better or worse).. >> >> 1. the CA/Browser Forum Extended Validation (EV) Certificate Guidelines >> explicitly allow for multiple CN-IDs >> >> 2. It's a not-totally-uncommon current practice to have certs that do >> have >> mutiple CN-IDs, eg from Comodo (whether EV or DV (domain valivdated)). >> >> 3. Virtual hosting multiple distinct-domain TLS servers on one entity is >> difficult today if one desires wide desktop client support because >> a certain vendor's older-but-still-widely-deployed-OS does not (yet?) >> support the TLS Server Name Indication extension. Thus having one >> cert with all the domains jammed in it (as either/both CN-IDs or/and >> DNS-IDs) is a workaround (eg Content Delivery Networks use this). >> >> >> So some argue that if we MUST NOT multiple CN-IDs at this point, it is >> flying in the face of present reality and might contribute to acquiring >> an attained reputation for this BCP that is lower than we desire. >> >> There is also concern on the part of CA folk about client-side TLS libs >> and their support for name matching (ie some (old?) one(s) will only >> match on CN-ID). >> >> For a CA perspective on all the above, see... >> >> Re: [certid] weird CN-IDs (subjectCommonName) in SSL Labs Survey Data >> http://www.ietf.org/mail-archive/web/certid/current/msg00502.html > >+1 to all that. Putting an explanation such as the above in the document will help future IETFs to decide when to make this a MUST NOT. It might also help the CA/Browser Forum and specific CAs see that they should stop doing this ASAP, and maybe even convince a particular legacy OS vendor to support TLS SNI. --Paul Hoffman, Director --VPN Consortium From stpeter@stpeter.im Tue Dec 7 07:29:37 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 4AD7E3A6808 for ; Tue, 7 Dec 2010 07:29:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.682 X-Spam-Level: X-Spam-Status: No, score=-102.682 tagged_above=-999 required=5 tests=[AWL=-0.083, BAYES_00=-2.599, 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 99oRCJFzPO24 for ; Tue, 7 Dec 2010 07:29:36 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id ED5993A67F1 for ; Tue, 7 Dec 2010 07:29:35 -0800 (PST) Received: from squire.local (ip-216-17-182-51.rev.frii.com [216.17.182.51]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id E0A1A400F6 for ; Tue, 7 Dec 2010 08:42:46 -0700 (MST) Message-ID: <4CFE532B.4040909@stpeter.im> Date: Tue, 07 Dec 2010 08:30:51 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: IETF cert-based identity X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms040406000401070408090702" Subject: [certid] regarding re-use 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, 07 Dec 2010 15:29:37 -0000 This is a cryptographically signed message in MIME format. --------------ms040406000401070408090702 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable This might be of interest regarding re-use of the server-id-check document... /psa -------- Original Message -------- Subject: Re: Peter Saint-Andre's DISCUSS on draft-igoe-secsh-x509v3-06 Date: Tue, 07 Dec 2010 08:22:25 -0700 From: Peter Saint-Andre To: Douglas Stebila CC: =3DJeffH , draft-igoe-secsh-x509v3@tools.ietf.org, The IESG , kmigoe@nsa.gov, jhutz@cmu.edu That's helpful regarding certificate issuance, but it doesn't say how the client is to perform comparisons. As you can see from the I-D I pointed you to, there are subtleties involved, such as internationalized domain names (IDNs) and so-called wildcard certificates (e.g., *.example.com). I didn't know the topic could be so interesting until I took over editorship of that document. :)= To compare identifiers of type dNSName, I suggest that you read http://tools.ietf.org/html/draft-saintandre-tls-server-id-check-11 if you haven't had a chance to do so yet, so that you have context for my proposed text, which is: ### For the purposes of user authentication, the mapping between certificates and user names is left as an implementation and configuration issue for implementers and system administrators. For the purposes of server authentication, it is RECOMMENDED that the subjectAlternativeName X.509v3 extension [RFC5280, Section 4.2.1.6] be used to convey the server host name, using either dNSName entries or iPAddress entries to convey domain names or IP addresses as appropriate. Multiple entries MAY be specified. The following rules apply: o If the client's reference identifier is a DNS domain name, the server's identity MUST be checked using the rules specified in [TLS-CERTS]. Support for the DNS-ID identifier type is REQUIRED in client and server software implementations. Certification authorities that issue certificates for use by Secure Shell servers MUST support the DNS-ID identifier type. Service providers SHOULD include the DNS-ID identifier type in certificate requests. The DNS-ID MAY contain the wildcard character '*' as the complete left-most label within the identifier. o If the client's reference identifier is an IP address as defined by [RFC791] or [RFC2460], the client MUST convert that address to the "network byte order" octet string representation and compare it against a subjectAltName entry of type iPAddress. A match occurs if the octet strings are identifier for the reference identifier and any presented identifier. ### See draft-saintandre-tls-server-id-check for the relevant terminology, and draft-ietf-xmpp-3920bis (Section 13.7.1.2.1) for a similar re-use of the server-id-check document. I've borrowed the IP address text from an earlier version of the server-id-check document (in later versions we focused the document only on DNS domain names and pulled out coverage of IP addresses): http://tools.ietf.org/html/draft-saintandre-tls-server-id-check-02#sectio= n-3.2.2 Naturally, YMMV and I welcome your thoughts on this approach. (I've cc'd my co-author on the server-id-check document to keep him in the loop as well.) Peter On 12/6/10 7:16 AM, Douglas Stebila wrote: > Thank you for the suggestion. What do you think of the following > change? >=20 > For the purposes of server authentication, it is RECOMMENDED that the > subjectAlternativeName X.509v3 extension [RFC5280, Section 4.2.1.6] > be used to convey the server host name, using either dNSName entries > or iPAddress entries to convey domain names or IP addresses as > appropriate; multiple entries MAY be specified. Additional > mechanisms mappings between certificates and host names are OPTIONAL > and are left as an implementation and configuration issue for > implementers and system administrators. >=20 > Douglas >=20 > On 2010-Dec-1, at 12:14 PM, Peter Saint-Andre wrote: >=20 >> ----------------------------------------------------------------------= >> >>=20 DISCUSS: >> ----------------------------------------------------------------------= >> >> >>=20 Section 4 states: >>=20 >> For the purposes of server authentication, the mapping between=20 >> certificates and host names is left as an implementation and=20 >> configuration issue for implementers and system administrators. >>=20 >> Leaving this up to software implementers and service operators >> seems shortsighted. For the sake of interoperability and improved >> security, I think it would be good to specify rules for checking >> the identity of hostnames asserted by the server (if the client >> does not check the server's identity, how can it be said to have >> authenticated the server?). It might be appropriate to cite >> draft-saintandre-tls-server-id-check or to borrow some text from >> that document. --------------ms040406000401070408090702 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/ jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q 7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo 98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR 6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV 0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD 0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri 2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6 wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1 nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2 gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1 My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo 6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3 GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6 2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4 TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0 ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+ 39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c 6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2 0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0 H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0 dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTIw NzE1MzA1MVowIwYJKoZIhvcNAQkEMRYEFGbRHnJN5hRZQ7VSHQumYYm4Hh11MF8GCSqGSIb3 DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG 9w0BAQEFAASCAQCzOLrn64ynxs74rTcEpTxLj7JIYx9JMH/l4mLgkbV/iCxlfKDt0UXSq2H2 4161Fmb0VLfXl/ZTQcJ/hoSb+7MgDrbjjYUD6IpPfjnWaubnSNeUx7cqOQ800+Em5E7bOxQX QXmd+mitSHCGzsg6qj9niO/BiPDPBF9VIV27QSMKrLuJ+jDbv2VTmuB9bI4x3GWOdgcBDcM2 a7zWoo5oHHSEJs1fCjAHZi7dK3sKEoDpAU8B9U21gEZ0bVS9zdnj6mzzZTN7Th5Z4vOItZHZ MRmEv/cK3/R4T3u2QVkuyV/tw0m51oRjmMZoTwwdSBFAcdLHGIMkZ/0Hk+y48JrMk2KCAAAA AAAA --------------ms040406000401070408090702-- From stpeter@stpeter.im Tue Dec 7 11:28: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 487E03A689A; Tue, 7 Dec 2010 11:28:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.486 X-Spam-Level: X-Spam-Status: No, score=-102.486 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, 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 ZLtibD4sZYmi; Tue, 7 Dec 2010 11:28:32 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id E71D13A6891; Tue, 7 Dec 2010 11:28:31 -0800 (PST) Received: from dhcp-64-101-72-234.cisco.com (dhcp-64-101-72-234.cisco.com [64.101.72.234]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id F3165400F6; Tue, 7 Dec 2010 12:41:43 -0700 (MST) Message-ID: <4CFE8B33.8020805@stpeter.im> Date: Tue, 07 Dec 2010 12:29:55 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: Ben Campbell References: In-Reply-To: X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms040103060900020300060308" Cc: draft-saintandre-tls-server-id-check.all@tools.ietf.org, General Area Review Team , certid@ietf.org Subject: Re: [certid] Gen-ART LC Review of draft-saintandre-tls-server-id-check-11 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, 07 Dec 2010 19:28:36 -0000 This is a cryptographically signed message in MIME format. --------------ms040103060900020300060308 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Regarding NAPTR... On 12/6/10 10:19 AM, Ben Campbell wrote: > -- 1.4.2, 2nd bullet item: "We also do not address identifiers > derived from Naming Authority Pointer (NAPTR) DNS resource records > [NAPTR] and related technologies such as [S-NAPTR], since such > identifiers cannot be validated in a trusted manner in the absence of > [DNSSEC]." >=20 > Does that mean validation of a source domain that will be used to > construct a NAPTR request is out of scope, or just validation against > the result of a NAPTR query? (I note SIP may require the first). Ben, the current text in the I-D is lame. The points we were trying to make, but poorly, are that (1) there are no identifiers for NAPTR records, as there are for SRV records, and (2) from the perspective of this spec it doesn't really matter how you get from the source domain to the IP address you use for communication (perhaps you do the A/AAAA one-step, the SRV two-step, or the NAPTR three-step, but that's immaterial for the purpose of identity checking). Point #1 is close to obvious, so I suggest that we remove the offending sentence and add this paragraph near the end of Section 1.4.2: Although the process whereby a client resolves the DNS domain name of an application service can involve several steps (e.g., this is true of resolutions that depend on DNS SRV resource records, Naming Authority Pointer (NAPTR) DNS resource records [NAPTR], and related technologies such as [S-NAPTR]), for our purposes we care only about the fact that the client needs to verify the identity of the entity with which it communicates as a result of the resolution process. The resolution process itself is out of scope. Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms040103060900020300060308 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/ jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q 7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo 98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR 6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV 0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD 0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri 2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6 wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1 nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2 gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1 My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo 6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3 GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6 2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4 TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0 ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+ 39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c 6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2 0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0 H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0 dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTIw NzE5Mjk1NVowIwYJKoZIhvcNAQkEMRYEFMlrrAPk3tJppJH0fS4Y72J8JBUCMF8GCSqGSIb3 DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG 9w0BAQEFAASCAQBolgdkmm9iMsw4qr7oxR4hGFYSxcKEVj0ZEVaw8240NL8LNBmywKgaf2GJ 6LMIuEhJpH8lcvUJqxb8Boy+9pv68zT3KiyjDtwxMpqgzgYxi03JoCidcB0UnlUFkGGfxw15 niPkG/qEsptqk3wlTlKgfuj3kkCsLj3szZVLnJywZ2qSjI36vz6zZXaL4jGVGmo5dSkF0jeI oOcLUozXmcv+wGdqcwh8TXeR4M1e2xTa8uTkDtUUSMiLqpBde9S2NX5DQqNXjsOh/PTlGAuo rpMOHwq70RiySax8txrAkLkkjurlk19hfeNLf8bz2vFT2XpJ5fsMVPn08tadQNZ1W+PxAAAA AAAA --------------ms040103060900020300060308-- From stpeter@stpeter.im Tue Dec 7 11:54: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 EFD1F3A6884; Tue, 7 Dec 2010 11:54:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.492 X-Spam-Level: X-Spam-Status: No, score=-102.492 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, 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 c8QFRo+Q+FC5; Tue, 7 Dec 2010 11:54:44 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id B796F3A67FF; Tue, 7 Dec 2010 11:54:44 -0800 (PST) Received: from dhcp-64-101-72-234.cisco.com (dhcp-64-101-72-234.cisco.com [64.101.72.234]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 348E24009B; Tue, 7 Dec 2010 13:07:57 -0700 (MST) Message-ID: <4CFE9159.2050502@stpeter.im> Date: Tue, 07 Dec 2010 12:56:09 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: Paul Hoffman References: <4CFD8731.9060208@KingsMountain.com> <4CFDB3CF.60507@stpeter.im> In-Reply-To: X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090605010105090507050501" Cc: Ben Campbell , General Area Review Team , IETF cert-based identity , =JeffH , draft-saintandre-tls-server-id-check.all@tools.ietf.org Subject: Re: [certid] Gen-ART LC Review of draft-saintandre-tls-server-id-check-11 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, 07 Dec 2010 19:54:46 -0000 This is a cryptographically signed message in MIME format. --------------ms090605010105090507050501 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 12/7/10 8:01 AM, Paul Hoffman wrote: > [[ Much abbreviated ]] >=20 > At 9:10 PM -0700 12/6/10, Peter Saint-Andre wrote: >>>>> -- 3.1, rule 6: >>>>> >>>>> Can you motivate why this is not a MUST NOT? >>> The reason for allowing this wiggle-room is that (for better or worse= ).. >>> >>> 1. the CA/Browser Forum Extended Validation (EV) Certificate Guidel= ines >>> explicitly allow for multiple CN-IDs >>> >>> 2. It's a not-totally-uncommon current practice to have certs that = do >>> have >>> mutiple CN-IDs, eg from Comodo (whether EV or DV (domain valivda= ted)). >>> >>> 3. Virtual hosting multiple distinct-domain TLS servers on one enti= ty is >>> difficult today if one desires wide desktop client support becau= se >>> a certain vendor's older-but-still-widely-deployed-OS does not (= yet?) >>> support the TLS Server Name Indication extension. Thus having on= e >>> cert with all the domains jammed in it (as either/both CN-IDs or= /and >>> DNS-IDs) is a workaround (eg Content Delivery Networks use this)= =2E >>> >>> >>> So some argue that if we MUST NOT multiple CN-IDs at this point, it i= s >>> flying in the face of present reality and might contribute to acquiri= ng >>> an attained reputation for this BCP that is lower than we desire. >>> >>> There is also concern on the part of CA folk about client-side TLS li= bs >>> and their support for name matching (ie some (old?) one(s) will only >>> match on CN-ID). >>> >>> For a CA perspective on all the above, see... >>> >>> Re: [certid] weird CN-IDs (subjectCommonName) in SSL Labs Survey Data= >>> http://www.ietf.org/mail-archive/web/certid/current/msg00502.html >> >> +1 to all that. >=20 > Putting an explanation such as the above in the document will help futu= re IETFs to decide when to make this a MUST NOT. It might also help the C= A/Browser Forum and specific CAs see that they should stop doing this ASA= P, and maybe even convince a particular legacy OS vendor to support TLS S= NI. Sigh. I don't particularly want to add a long informational note that qualifies eight words in the spec, but you're right. :) Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms090605010105090507050501 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/ jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q 7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo 98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR 6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV 0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD 0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri 2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6 wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1 nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2 gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1 My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo 6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3 GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6 2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4 TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0 ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+ 39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c 6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2 0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0 H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0 dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTIw NzE5NTYwOVowIwYJKoZIhvcNAQkEMRYEFFvo0T2TpY7WdyymA5ukIk60j0g5MF8GCSqGSIb3 DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG 9w0BAQEFAASCAQAY7JLdbQfFrZ6UXTZJqnrZeZqJFzDyLTS8mgrqn0Da/0GDy0dvjf/QCLnb a7OeiWUPBUgxoFWLUM1KIMgfcKWzu+YrJ30tKLjn0LsIEaCcoa9OL5iFg+b0OY1JGX9TVkje NJe5ID/M2G+lAHWXMjKY6WbuZ3eyzuTG9FWBXKoQQS5aWuAoGgd3Qm398gp+oBrqlV5qUIfb gmXCUqmf+fW0cMd+54Wgid3qw7sbaWJktLBBNjas1eEVEZnXM0DtzcX/g0LXS95RrEHuOUvl 2hhkUy5eVWEDKzK9yVcNdmxmL7FOVNbi10jBmkUGXPFw7LysQ7kqEhduWd4yBMkOmVMbAAAA AAAA --------------ms090605010105090507050501-- From stpeter@stpeter.im Tue Dec 7 14:13: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 1143328C0F3; Tue, 7 Dec 2010 14:13:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.497 X-Spam-Level: X-Spam-Status: No, score=-102.497 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, 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 3WeIvIPHecQs; Tue, 7 Dec 2010 14:13:06 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 1254C28C0F6; Tue, 7 Dec 2010 14:13:06 -0800 (PST) Received: from dhcp-64-101-72-234.cisco.com (dhcp-64-101-72-234.cisco.com [64.101.72.234]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 2E2BE4009B; Tue, 7 Dec 2010 15:26:19 -0700 (MST) Message-ID: <4CFEB1C5.4010103@stpeter.im> Date: Tue, 07 Dec 2010 15:14:29 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: Ben Campbell References: In-Reply-To: X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms030000020508040804050403" Cc: draft-saintandre-tls-server-id-check.all@tools.ietf.org, General Area Review Team , certid@ietf.org Subject: Re: [certid] Gen-ART LC Review of draft-saintandre-tls-server-id-check-11 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, 07 Dec 2010 22:13:08 -0000 This is a cryptographically signed message in MIME format. --------------ms030000020508040804050403 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Ben, I've looked again at the URI-ID issue, with special reference to SIP domain certs (RFC 5922) because SIP seems to be the main technology that uses URI-IDs. Some of what follows is me thinking out loud. I'll need to check any tentative conclusions with my co-author. Also, please note that in this I-D Jeff and I have been working to generalize from current practices. That's a bit difficult in the case of URI-IDs because we seem to have only one instance (RFC 5922). I'll ask the PKIX WG if folks are aware of any other "customers" for the uniformResourceIdentifier SAN. On 12/6/10 10:19 AM, Ben Campbell wrote: > -- [ Not so much a "major issue" as a "slightly less minor" one] I'd > like to see more discussion around URI-IDs. These seem to me to be > the most complex ID type to get right, but there are no examples and > limited discussion. Picking on SIP, purely as an example for which I > have a passing familiarity: Would a SIP reference identity match a > SIPS URI-ID in a certificate?=20 RFC 5630 states: SIP and SIPS URIs that are identical except for the scheme itself (e.g., sip:alice@example.com and sips:alice@example.com) refer to the same resource. This requirement is implicit in [RFC3261], Section 19.1, which states that "any resource described by a SIP URI can be 'upgraded' to a SIPS URI by just changing the scheme, if it is desired to communicate with that resource securely". So the two are interchangeable: a SIPS reference identity can be compared against a SIP URI-ID and vice-versa. However, that equivalence is stipulated by the SIP specs and it is not something we could generalize to all uses of URI-IDs (say, http and https). And RFC 5922 says that the scheme of the presented identifier MUST be sip, not sips, so that's a further SIP-specific wrinkle. > Do I put both a URI-ID and an SRV-ID in > my reference set and/or certificate?=20 That depends. :) A using protocol needs to specify what identifier types are required and recommended for that application type. For example, in draft-ietf-xmpp-3920bis we've specified some guidelines for XMPP server certificates, but the guidelines used in the SIP or HTTP or IMAP community would be different (if those communities ever become "customers" of the server-id-check specification). > How do I handle the fact that I > sometimes need to do a NAPTR query, before the SRV query depending on > whether I know the transport protocol? (I realize SIP already defines > cert ID matching, but what would I do for a new application protocol > URI with similar properties?) I think you would take the input to the NAPTR lookup as the source domain, just as you would for an SRV lookup or an A or AAAA lookup. Potentially there are more complexities in a NAPTR lookup (all that regex fun). Furthermore, the NAPTR result might lead the user agent to then perform an SRV lookup and then an A/AAAA lookup on the result of the SRV lookup (which is why I call it "the NAPTR three-step"). But I think that from the perspective of identity checking it doesn't make a difference how many steps are contained in the resolution process. See previous message. > I wonder if the answer is that such things are scheme specific, and > that its hard to say much about the generic handling of URI-IDs.=20 I think we can say that the client needs to separate the application type aspect of the URI-ID from the the DNS domain name aspect, and we do say that in Section 4.3: ### Before applying the comparison rules provided in the following sections, the client might need to split the reference identifier into its DNS domain name portion and its application type portion, as follows: [...] o For a reference identifier of type URI-ID, the DNS domain name portion is the "reg-name" part of the "authority" component and the application type portion is the scheme name matching the [ABNF] "scheme" rule from [URI] (not including the ':' separator); note that this document specifies that a URI-ID always contains an "authority" component whose "host" subcomponent contains a "reg- name" (matching only the "reg-name" rule from [URI] limits verification to DNS domain names, differentiating a URI-ID from a uniformResourceIdentifier entry that contains an IP address or a mere host name, or that does not contain an "authority" component), and that extraction of the "reg-name" might necessitate normalization of the URI (as explained in [URI]). ### The client then follows the rules for matching the DNS domain name portion as specified in server-id-check document. So I think that the URI-ID type is not all that different from the others. (There are complexities caused by URI normalization. I think it's best to point to RFC 3986 regarding such issues, rather than trying to describe them all in this spec.) > If > so, it might be worth mentioning that, and maybe discuss what things > the designer of a new scheme should keep in mind. The designer of a new scheme, or the author of a specification that re-uses the recommendations in the server-id-check document? If the former, I think that's a job for other documents (4395bis?). If the latter, I don't particularly see that we can say much -- this is something that each technology community will need to consider, but really the only choices are: 1. Which of CN-ID, DNS-ID, SRV-ID, and URI-ID do we recommend? 2. Do we allow wildcards? If so, exactly where? > -- 3.1, rule 3: >=20 > What happens when you have multiple schemes that are defined to refer > to the same resource. For example, SIP and SIPS? Does a SIP URI-ID > match an otherwise identical SIPS URI-ID? (Maybe this should be left > to the URI definitions themselves, but it might be worth mentioning > the complication somewhere.) Right, so that is a third choice facing authors of specifications that re-use this one. I propose modifying the relevant paragraph in Section 3.1 as follows: 3. If the service using the certificate deploys a technology in which a server is typically associated with a URI (e.g., this is true of [SIP]), then the certificate SHOULD include a URI-ID; the scheme SHALL be that of the protocol associated with the service type and the "authority" component SHALL be the fully-qualified DNS domain name of the service. A specification that re-uses this one MUST specify whether particular URI schemes are to be considered equivalent (e.g., http and https, or sip and sips as described in [RFC5630]). (But see below, where I propose further modifications to that paragraph to address another issue you've raised.) > -- section 3.2: >=20 > I'd like to see a (non-trivial) URL-ID example. How's this? Consider a SIP-accessible voice-over-IP (VoIP) server at "voice.example.edu" servicing SIP addresses of the form "user@voice.example.edu" and located at a URI of . A certificate for this service would include a URI-ID of "sip:voice.example.edu" (see [SIP-CERTS]). Is that example "trivial", compared to the other examples in the spec? > --4.2.1, paragraph 3: >=20 > It's probably out of scope, but it might be useful to offer some > guidance on how ensuring the extraction is "not subject to > subversion" is not always trivial. For example, if you got your input > URI by clicking on a link in a phishing email, that can be almost > isomorphic to using a delegation from a non-trusted source. I suggest modifying the relevant paragraph as follows (see the last sentence): The client might need to extract the source domain and service type from the input(s) it has received. The extracted data MUST include only information that can be securely parsed out of the inputs (e.g., extracting the fully-qualified DNS domain name from the "authority" component of a URI or extracting the service type from the scheme of a URI) or information for which the extraction is performed in a manner that is not subject to subversion by network attackers (e.g., pulling the data from a delegated domain that is explicitly established via client or system configuration, resolving the data via [DNSSEC], or obtaining the data from a third-party domain mapping service in which a human user has explicitly placed trust and with which the client communicates over a connection that provides both mutual authentication and integrity checking). These considerations apply only to extraction of the source domain from the inputs; naturally, if the inputs themselves are invalid or corrupt (e.g., a user has clicked a link provided by a malicious entity in a phishing attack), then the client might end up communicating with an unexpected application service. > -- 4.2.2: >=20 > Can we have a URI-ID example?=20 How's this? A voice-over-IP (VoIP) user agent that is connecting via SIP to the voice service at "voice.example.edu" might have only one reference identifier: a URI-ID of "sip:voice.example.edu" (see [SIP-CERTS]). > (and maybe an explanation why the HTTP > example doesn't use one?) Well, we happen to know that no one does it that way. :) However, we might need to tighten up the wording here: 3. If the service using the certificate deploys a technology in which a server is typically associated with a URI (e.g., this is true of [SIP]), then the certificate SHOULD include a URI-ID.... Specifically, we might need to say "programatically associated with a URI for security purposes" or somesuch. This I-D is decidedly *not* attempting to modify how existing technologies use PKIX certificates, so it would be improper for us to have a URI-ID example for HTTP. I suggest the following tweaks: 3. If the service using the certificate deploys a technology in which a server is programatically associated with a URI for security purposes (e.g., this is true of [SIP] as specified by [SIP-CERTS]), but not true of [HTTP] since [HTTP-TLS] does not describe usage of a URI-ID for HTTP services), then the certificate SHOULD include a URI-ID; the scheme SHALL be that of the protocol associated with the service type and the "authority" component SHALL be the fully-qualified DNS domain name of the service. A specification that re-uses this one MUST specify whether particular URI schemes are to be considered equivalent (e.g., http and https, or sip and sips as described in [SIP-SIPS]). > -- 4.3, 4th bullet item: >=20 > An example would be helpful here. Yep, I propose that we add examples to all of those bullet points: ### Before applying the comparison rules provided in the following sections, the client might need to split the reference identifier into its DNS domain name portion and its application type portion, as follows: o A reference identifier of type DNS-ID does not include an application type portion and thus can be used directly as the DNS domain name for comparison purposes. As an example, a DNS-ID of "www.example.com" would result in a DNS domain name portion of "www.example.com". o A reference identifier of type CN-ID also does not include an application type portion and thus can be used directly as the DNS domain name for comparison purposes. As previously mentioned, this document specifies that a CN-ID always contains a string whose form matches that of a DNS domain name (thus differentiating a CN-ID from a Common Name containing a human-friendly name). o For a reference identifier of type SRV-ID, the DNS domain name portion is the Name and the application type portion is the Service. As an example, an SRV-ID of "_imaps.mail.example.net" would be split into a DNS domain name portion of "mail.example.net" and an application type portion of "imaps" (mapping to an application protocol of IMAP as explained in [EMAIL-SRV]). o For a reference identifier of type URI-ID, the DNS domain name portion is the "reg-name" part of the "authority" component and the application type portion is the scheme name matching the [ABNF] "scheme" rule from [URI] (not including the ':' separator). As previously mentioned, this document specifies that a URI-ID always contains an "authority" component whose "host" subcomponent contains a "reg-name". (Matching only the "reg-name" rule from [URI] limits verification to DNS domain names, thereby differentiating a URI-ID from a uniformResourceIdentifier entry that contains an IP address or a mere host name, or that does not contain an "authority" component at all.). Furthermore, note that extraction of the "reg-name" might necessitate normalization of the URI (as explained in [URI]. As an example, a URI-ID of "sip: voice.example.edu" would be split into a DNS domain name portion of "voice.example.edu" and an application type of "sip" (mapping to an application protocol of SIP as explained in [SIP-CERTS]). ### Again, those are all proposals. Ben, let us know if those address your questions. Jeff, let me know if you disagree with your co-author. :) Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms030000020508040804050403 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/ jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q 7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo 98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR 6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV 0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD 0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri 2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6 wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1 nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2 gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1 My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo 6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3 GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6 2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4 TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0 ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+ 39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c 6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2 0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0 H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0 dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTIw NzIyMTQyOVowIwYJKoZIhvcNAQkEMRYEFH03j8LyvfeJDENVjsNkoiMJvctyMF8GCSqGSIb3 DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG 9w0BAQEFAASCAQBj0FebbXPI927TLNqtQV0AGNqF9Tm9kNOHW6imvAajjr0nt7VKYN7PkJj6 mcpDgO/o6+JmubvkRLZhA5By/HiiLPcv6TGbgp2tGnPQInz8VcBL4oQnX4V7A3C4leNjGdTl cXQyPSSWeDEfLXhwbIW9bh3PwXVvuIDHqTvIolVtC46jDgSMIMJM6eyLskTcgh3eYlpS2LLp yLHVqYqmnl7zaG4cgkyO1Bn/wRWsdN4BBt+Z4frMhNJxHji7QgLLFHEdNj0Tp8qM4Bd7Fo8E I4uhOxOosRwHvYlBngafwPi+06IIutYtaPIhixoKZPPGj+RGeoZre499IfahJxc1D2ctAAAA AAAA --------------ms030000020508040804050403-- From ben@nostrum.com Tue Dec 7 16:08: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 15F683A683D; Tue, 7 Dec 2010 16:08:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.292 X-Spam-Level: X-Spam-Status: No, score=-102.292 tagged_above=-999 required=5 tests=[AWL=0.308, BAYES_00=-2.599, SPF_PASS=-0.001, 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 aBq50XXpGIcm; Tue, 7 Dec 2010 16:08:54 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 2DFDB3A68B6; Tue, 7 Dec 2010 16:08:52 -0800 (PST) Received: from [10.0.1.6] (cpe-76-183-178-106.tx.res.rr.com [76.183.178.106]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id oB80ADZ5072527 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 7 Dec 2010 18:10:13 -0600 (CST) (envelope-from ben@nostrum.com) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Ben Campbell In-Reply-To: <4CFEB1C5.4010103@stpeter.im> Date: Tue, 7 Dec 2010 18:10:08 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4CFEB1C5.4010103@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1082) Received-SPF: pass (nostrum.com: 76.183.178.106 is authenticated by a trusted mechanism) X-Mailman-Approved-At: Tue, 07 Dec 2010 17:46:17 -0800 Cc: draft-saintandre-tls-server-id-check.all@tools.ietf.org, General Area Review Team , certid@ietf.org Subject: Re: [certid] Gen-ART LC Review of draft-saintandre-tls-server-id-check-11 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, 08 Dec 2010 00:08:57 -0000 I'm jumping in a bit late with some review followup. It's not entirely = clear to me where in the thread I should re-insert myself, so I = apologize if I bring up stuff that would have been resolved or otherwise = obvious at other points in the thread--I'll dig back through and respond = further as appropriate. (And I realize I'm doing lots of arm-waving around whats-really-going-on = with URI-IDs and SIP. If we need a higher bandwidth communication, I can = be available.) Comments inline: On Dec 7, 2010, at 4:14 PM, Peter Saint-Andre wrote: > Hi Ben, I've looked again at the URI-ID issue, with special reference = to > SIP domain certs (RFC 5922) because SIP seems to be the main = technology > that uses URI-IDs. Some of what follows is me thinking out loud. I'll > need to check any tentative conclusions with my co-author. >=20 > Also, please note that in this I-D Jeff and I have been working to > generalize from current practices. That's a bit difficult in the case = of > URI-IDs because we seem to have only one instance (RFC 5922). I'll ask > the PKIX WG if folks are aware of any other "customers" for the > uniformResourceIdentifier SAN. >=20 Understood. It may be that the answer is that the use of URI-ID is not = sufficiently understood to offer general guidance. OTOH, in the case of = SIP, the URI-ID appears to be solely for the purpose of binding a domain = name to the service. Otherwise, the use as defined in RFC5922 would be = substantially identical to using a DNS-ID. More to the point, RFC5922 = does not use URI-ID to specify a user identity, only a host identity. = Would you recommend designers of a new protocol to follow that pattern? = I note that (unless I missed it) the 5922 doesn't seem to allow for = falling back to a dNSName. Is that a reasonable choice for a new = protocol to make? (And doesn't this feel a lot like using SRV-IDs?) Now compare that to HTTP using a DNS-ID. The two are trying to = accomplish the same thing, in that they are identifying a domain name, = not a resource (in the case of HTTP) or a user (in the case of SIP). Can = we generalize anything from that? If we were starting over with either, = would we recommend HTTP use URI-ID, or perhaps SIP should not? I almost wonder if the best thing would be a discussion of what you = might could do with URI-ID, with very little normative stuff. If you = want to identify a host and service only, here's how. If you want to = identify something more like a resource, then do this other thing (or = say it''s out of scope).=20 > On 12/6/10 10:19 AM, Ben Campbell wrote: >=20 >> -- [ Not so much a "major issue" as a "slightly less minor" one] I'd >> like to see more discussion around URI-IDs. These seem to me to be >> the most complex ID type to get right, but there are no examples and >> limited discussion. Picking on SIP, purely as an example for which I >> have a passing familiarity: Would a SIP reference identity match a >> SIPS URI-ID in a certificate?=20 >=20 > RFC 5630 states: >=20 > SIP and SIPS URIs that are identical except for the scheme itself > (e.g., sip:alice@example.com and sips:alice@example.com) refer to = the > same resource. This requirement is implicit in [RFC3261], Section > 19.1, which states that "any resource described by a SIP URI can be > 'upgraded' to a SIPS URI by just changing the scheme, if it is > desired to communicate with that resource securely". >=20 > So the two are interchangeable: a SIPS reference identity can be > compared against a SIP URI-ID and vice-versa. However, that = equivalence > is stipulated by the SIP specs and it is not something we could > generalize to all uses of URI-IDs (say, http and https). And RFC 5922 > says that the scheme of the presented identifier MUST be sip, not = sips, > so that's a further SIP-specific wrinkle. Yeah, that's an interesting one. On reflection, I think RFC 5922 is, = again, trying to match _service_ more than a URI scheme. The service is = "sip" regardless of whether you started with a SIPS URI. When you = consider the further complication of TEL URIs (e.g. tel:+18005551212), = you're _still_ looking for a SIP service. This is pretty much what I = think you had in mind in the section 4.3 text on URI_IDs, except that = the service is implied by the fact that its a SIP application in the = first place, rather than simply copied from some specific URI.=20 If this is the correct interpretation of 5922, then the SIPS/SIP = equivalence is probably a red herring. I'd certainly be interested to = hear the RFC 5922 author's thoughts on that. For that matter, I think that XMPP and SIP both needed to accomplish the = same thing--match a source domain name and a service. Both SRV-IDs and = URI-IDs can do that, but they made opposite choices. I suspect the = choices were along the lines of "XMPP doesn't _use_ URIs, and SIP does". = But it doesn't seem like SIP is really matching against a URI . And you = could just as easily synthesize an XMPP scheme and use URI-IDs--but the = awkwardness becomes more obvious there. >=20 >> Do I put both a URI-ID and an SRV-ID in >> my reference set and/or certificate?=20 >=20 > That depends. :) A using protocol needs to specify what identifier = types > are required and recommended for that application type. For example, = in > draft-ietf-xmpp-3920bis we've specified some guidelines for XMPP = server > certificates, but the guidelines used in the SIP or HTTP or IMAP > community would be different (if those communities ever become > "customers" of the server-id-check specification). Right. But this document endeavors to recommend what people should put = in their specs for future protocols, right? Or does it just discuss = things they need to think about in their specs? I meant the SIP = questions as examples. They would probably been better stated as "What = should the new FUBAR protocol, which uses URIs and DNS in a way = functionally identical to SIP, do?" The bottom line is, should this draft offer guidance on the best way to = match a source domain and service? Or is it to say "here's some ways you = can do it, pick one (or some)." I'm okay either way, but it would be = best to be explicit. >=20 >> How do I handle the fact that I >> sometimes need to do a NAPTR query, before the SRV query depending on >> whether I know the transport protocol? (I realize SIP already defines >> cert ID matching, but what would I do for a new application protocol >> URI with similar properties?) >=20 > I think you would take the input to the NAPTR lookup as the source > domain, just as you would for an SRV lookup or an A or AAAA lookup. > Potentially there are more complexities in a NAPTR lookup (all that > regex fun). Furthermore, the NAPTR result might lead the user agent to > then perform an SRV lookup and then an A/AAAA lookup on the result of > the SRV lookup (which is why I call it "the NAPTR three-step"). But I > think that from the perspective of identity checking it doesn't make a > difference how many steps are contained in the resolution process. See > previous message. I agree, that's the way it is supposed to work for SIP. Do you think = that it would be obvious to the hypothetical FUBAR designers whether = they should do the same? (I'm not saying it's not--I would need to = reread the draft with that in mind, and haven't done so yet.) >=20 >> I wonder if the answer is that such things are scheme specific, and >> that its hard to say much about the generic handling of URI-IDs.=20 >=20 > I think we can say that the client needs to separate the application > type aspect of the URI-ID from the the DNS domain name aspect, and we = do > say that in Section 4.3: >=20 > ### >=20 > Before applying the comparison rules provided in the following > sections, the client might need to split the reference identifier > into its DNS domain name portion and its application type portion, = as > follows: >=20 > [...] >=20 > o For a reference identifier of type URI-ID, the DNS domain name > portion is the "reg-name" part of the "authority" component and > the application type portion is the scheme name matching the > [ABNF] "scheme" rule from [URI] (not including the ':' = separator); > note that this document specifies that a URI-ID always contains = an > "authority" component whose "host" subcomponent contains a "reg- > name" (matching only the "reg-name" rule from [URI] limits > verification to DNS domain names, differentiating a URI-ID from a > uniformResourceIdentifier entry that contains an IP address or a > mere host name, or that does not contain an "authority" > component), and that extraction of the "reg-name" might > necessitate normalization of the URI (as explained in [URI]). >=20 > ### >=20 > The client then follows the rules for matching the DNS domain name > portion as specified in server-id-check document. So I think that the > URI-ID type is not all that different from the others. Is it your expectation that no protocol should try to include other, = more resourcey parts of a URI for the purposes of cert matching? Or that = that sort of thing should be out of scope? >=20 > (There are complexities caused by URI normalization. I think it's best > to point to RFC 3986 regarding such issues, rather than trying to > describe them all in this spec.) >=20 >> If >> so, it might be worth mentioning that, and maybe discuss what things >> the designer of a new scheme should keep in mind. >=20 > The designer of a new scheme, or the author of a specification that > re-uses the recommendations in the server-id-check document? The second, keeping in mine that new scheme design often happens as a = part of such an effort, even if the documents are split. (Would cert = matching be scheme specific, or protocol specific?) >=20 > If the former, I think that's a job for other documents (4395bis?). >=20 > If the latter, I don't particularly see that we can say much -- this = is > something that each technology community will need to consider, but > really the only choices are: >=20 > 1. Which of CN-ID, DNS-ID, SRV-ID, and URI-ID do we recommend? >=20 > 2. Do we allow wildcards? If so, exactly where? Recommendations about how to choose between DNS-ID, SRV-ID, and URI-ID = would be out of scope for this document, then, right? I think that = answers my previous question about how much the draft tries to = recommend. >=20 >> -- 3.1, rule 3: >>=20 >> What happens when you have multiple schemes that are defined to refer >> to the same resource. For example, SIP and SIPS? Does a SIP URI-ID >> match an otherwise identical SIPS URI-ID? (Maybe this should be left >> to the URI definitions themselves, but it might be worth mentioning >> the complication somewhere.) >=20 > Right, so that is a third choice facing authors of specifications that > re-use this one. I propose modifying the relevant paragraph in Section > 3.1 as follows: >=20 > 3. If the service using the certificate deploys a technology in > which a server is typically associated with a URI (e.g., this is > true of [SIP]), then the certificate SHOULD include a URI-ID; = the > scheme SHALL be that of the protocol associated with the service > type and the "authority" component SHALL be the fully-qualified > DNS domain name of the service. A specification that re-uses > this one MUST specify whether particular URI schemes are to be > considered equivalent (e.g., http and https, or sip and sips as > described in [RFC5630]). Given the previous conversation about how SIP seems to be the only = protocol with the equivalent scheme issue that actually uses URI-IDs, = and that it doesn't seem to need to worry about which scheme its using = at the moment, I no longer think this draft needs to worry about it. If = it were to say anything at all along those lines, it would probably need = to be along the lines of KISS. For example, I don't think you want = designers trying to assert security properties by which scheme they = include in a cert (i.e. "foo" vs "foos") >=20 > (But see below, where I propose further modifications to that = paragraph > to address another issue you've raised.) >=20 >> -- section 3.2: >>=20 >> I'd like to see a (non-trivial) URL-ID example. >=20 > How's this? >=20 > Consider a SIP-accessible voice-over-IP (VoIP) server at > "voice.example.edu" servicing SIP addresses of the form > "user@voice.example.edu" and located at a URI of > . A certificate for this service > would include a URI-ID of "sip:voice.example.edu" (see > [SIP-CERTS]). >=20 > Is that example "trivial", compared to the other examples in the spec? No, I think that's a good one based on the discussion so far. (assuming = I am correct in my understanding that you don't expect to ever see = protocols match on user or resource information inside the URI.) It = might be worth mentioning in the example why the "user@" part is not = used. >=20 >> --4.2.1, paragraph 3: >>=20 >> It's probably out of scope, but it might be useful to offer some >> guidance on how ensuring the extraction is "not subject to >> subversion" is not always trivial. For example, if you got your input >> URI by clicking on a link in a phishing email, that can be almost >> isomorphic to using a delegation from a non-trusted source. >=20 > I suggest modifying the relevant paragraph as follows (see the last > sentence): >=20 > The client might need to extract the source domain and service type > from the input(s) it has received. The extracted data MUST include > only information that can be securely parsed out of the inputs = (e.g., > extracting the fully-qualified DNS domain name from the "authority" > component of a URI or extracting the service type from the scheme of > a URI) or information for which the extraction is performed in a > manner that is not subject to subversion by network attackers (e.g., > pulling the data from a delegated domain that is explicitly > established via client or system configuration, resolving the data > via [DNSSEC], or obtaining the data from a third-party domain = mapping > service in which a human user has explicitly placed trust and with > which the client communicates over a connection that provides both > mutual authentication and integrity checking). These considerations > apply only to extraction of the source domain from the inputs; > naturally, if the inputs themselves are invalid or corrupt (e.g., a > user has clicked a link provided by a malicious entity in a phishing > attack), then the client might end up communicating with an > unexpected application service. >=20 WFM >> -- 4.2.2: >>=20 >> Can we have a URI-ID example?=20 >=20 > How's this? >=20 > A voice-over-IP (VoIP) user agent that is connecting via SIP to the > voice service at "voice.example.edu" might have only one reference > identifier: a URI-ID of "sip:voice.example.edu" (see [SIP-CERTS]). >=20 Would it make sense to say something to indicate this is true, even = though the connection may have been opened based on a URI of = "sip:user@voice.example.edu"? (I'm trying to figure out the best way to = word that without trying to invoke SIP request-URI vs route set = complexities, but my brain is tired. I will think further about it.) >> (and maybe an explanation why the HTTP >> example doesn't use one?) >=20 > Well, we happen to know that no one does it that way. :) >=20 > However, we might need to tighten up the wording here: >=20 > 3. If the service using the certificate deploys a technology in > which a server is typically associated with a URI (e.g., this is > true of [SIP]), then the certificate SHOULD include a URI-ID.... >=20 > Specifically, we might need to say "programatically associated with a > URI for security purposes" or somesuch. >=20 > This I-D is decidedly *not* attempting to modify how existing > technologies use PKIX certificates, so it would be improper for us to > have a URI-ID example for HTTP. Sure, the reason HTTP does not use is because HTTP isn't specified that = way :-) (i.e. for historical reasons.) >=20 > I suggest the following tweaks: >=20 > 3. If the service using the certificate deploys a technology in > which a server is programatically associated with a URI for > security purposes (e.g., this is true of [SIP] as specified by > [SIP-CERTS]), but not true of [HTTP] since [HTTP-TLS] does not > describe usage of a URI-ID for HTTP services), then the > certificate SHOULD include a URI-ID; the scheme SHALL be that of > the protocol associated with the service type and the = "authority" > component SHALL be the fully-qualified DNS domain name of the > service. A specification that re-uses this one MUST specify > whether particular URI schemes are to be considered equivalent > (e.g., http and https, or sip and sips as described in > [SIP-SIPS]). I think this is pretty close, modulo previous comments above. I wonder = if the fact that SIP appears to abstract the scheme rather than use the = scheme of any particular URI is relevant here, or just adds too much = complexity to the language. >=20 >> -- 4.3, 4th bullet item: >>=20 >> An example would be helpful here. >=20 > Yep, I propose that we add examples to all of those bullet points: Ah, okay. I was mainly picking on URI-IDs due to the lack of examples = elsewhere. But more examples (almost) never hurt. >=20 > ### >=20 > Before applying the comparison rules provided in the following > sections, the client might need to split the reference identifier > into its DNS domain name portion and its application type portion, = as > follows: >=20 > o A reference identifier of type DNS-ID does not include an > application type portion and thus can be used directly as the DNS > domain name for comparison purposes. As an example, a DNS-ID of > "www.example.com" would result in a DNS domain name portion of > "www.example.com". >=20 > o A reference identifier of type CN-ID also does not include an > application type portion and thus can be used directly as the DNS > domain name for comparison purposes. As previously mentioned, > this document specifies that a CN-ID always contains a string > whose form matches that of a DNS domain name (thus = differentiating > a CN-ID from a Common Name containing a human-friendly name). >=20 > o For a reference identifier of type SRV-ID, the DNS domain name > portion is the Name and the application type portion is the > Service. As an example, an SRV-ID of "_imaps.mail.example.net" > would be split into a DNS domain name portion of > "mail.example.net" and an application type portion of "imaps" > (mapping to an application protocol of IMAP as explained in > [EMAIL-SRV]). >=20 > o For a reference identifier of type URI-ID, the DNS domain name > portion is the "reg-name" part of the "authority" component and > the application type portion is the scheme name matching the > [ABNF] "scheme" rule from [URI] (not including the ':' = separator). > As previously mentioned, this document specifies that a URI-ID > always contains an "authority" component whose "host" = subcomponent > contains a "reg-name". (Matching only the "reg-name" rule from > [URI] limits verification to DNS domain names, thereby > differentiating a URI-ID from a uniformResourceIdentifier entry > that contains an IP address or a mere host name, or that does not > contain an "authority" component at all.). Furthermore, note = that > extraction of the "reg-name" might necessitate normalization of > the URI (as explained in [URI]. As an example, a URI-ID of "sip: > voice.example.edu" would be split into a DNS domain name portion > of "voice.example.edu" and an application type of "sip" (mapping > to an application protocol of SIP as explained in [SIP-CERTS]). > ### >=20 > Again, those are all proposals. Ben, let us know if those address your > questions. Jeff, let me know if you disagree with your co-author. :) >=20 > Peter >=20 > --=20 > Peter Saint-Andre > https://stpeter.im/ >=20 >=20 >=20 From ben@nostrum.com Tue Dec 7 16:13:18 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 DEB663A6881; Tue, 7 Dec 2010 16:13:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.317 X-Spam-Level: X-Spam-Status: No, score=-102.317 tagged_above=-999 required=5 tests=[AWL=0.283, BAYES_00=-2.599, SPF_PASS=-0.001, 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 YZmKIowdoCIM; Tue, 7 Dec 2010 16:13:17 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 46E113A687A; Tue, 7 Dec 2010 16:13:17 -0800 (PST) Received: from [10.0.1.6] (cpe-76-183-178-106.tx.res.rr.com [76.183.178.106]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id oB80EfQ2072860 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 7 Dec 2010 18:14:42 -0600 (CST) (envelope-from ben@nostrum.com) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Ben Campbell In-Reply-To: <4CFE8B33.8020805@stpeter.im> Date: Tue, 7 Dec 2010 18:14:41 -0600 Content-Transfer-Encoding: 7bit Message-Id: References: <4CFE8B33.8020805@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1082) Received-SPF: pass (nostrum.com: 76.183.178.106 is authenticated by a trusted mechanism) X-Mailman-Approved-At: Tue, 07 Dec 2010 17:46:17 -0800 Cc: draft-saintandre-tls-server-id-check.all@tools.ietf.org, General Area Review Team , certid@ietf.org Subject: Re: [certid] [Gen-art] Gen-ART LC Review of draft-saintandre-tls-server-id-check-11 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, 08 Dec 2010 00:13:19 -0000 WFM, thanks. On Dec 7, 2010, at 1:29 PM, Peter Saint-Andre wrote: > Regarding NAPTR... > > On 12/6/10 10:19 AM, Ben Campbell wrote: > >> -- 1.4.2, 2nd bullet item: "We also do not address identifiers >> derived from Naming Authority Pointer (NAPTR) DNS resource records >> [NAPTR] and related technologies such as [S-NAPTR], since such >> identifiers cannot be validated in a trusted manner in the absence of >> [DNSSEC]." >> >> Does that mean validation of a source domain that will be used to >> construct a NAPTR request is out of scope, or just validation against >> the result of a NAPTR query? (I note SIP may require the first). > > Ben, the current text in the I-D is lame. The points we were trying to > make, but poorly, are that (1) there are no identifiers for NAPTR > records, as there are for SRV records, and (2) from the perspective of > this spec it doesn't really matter how you get from the source domain to > the IP address you use for communication (perhaps you do the A/AAAA > one-step, the SRV two-step, or the NAPTR three-step, but that's > immaterial for the purpose of identity checking). > > Point #1 is close to obvious, so I suggest that we remove the offending > sentence and add this paragraph near the end of Section 1.4.2: > > Although the process whereby a client resolves the DNS domain name of > an application service can involve several steps (e.g., this is true > of resolutions that depend on DNS SRV resource records, Naming > Authority Pointer (NAPTR) DNS resource records [NAPTR], and related > technologies such as [S-NAPTR]), for our purposes we care only about > the fact that the client needs to verify the identity of the entity > with which it communicates as a result of the resolution process. > The resolution process itself is out of scope. > > Peter > > -- > Peter Saint-Andre > https://stpeter.im/ > > > > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art From ben@nostrum.com Tue Dec 7 17:34:30 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A85FE3A68DD; Tue, 7 Dec 2010 17:34:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.189 X-Spam-Level: X-Spam-Status: No, score=-101.189 tagged_above=-999 required=5 tests=[AWL=-0.889, BAYES_00=-2.599, MANGLED_LIST=2.3, SPF_PASS=-0.001, 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 9Wnkgw7i6UKC; Tue, 7 Dec 2010 17:34:17 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id F10553A69B8; Tue, 7 Dec 2010 17:34:14 -0800 (PST) Received: from [10.0.1.6] (cpe-76-183-178-106.tx.res.rr.com [76.183.178.106]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id oB81ZboD078789 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 7 Dec 2010 19:35:38 -0600 (CST) (envelope-from ben@nostrum.com) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=iso-8859-1 From: Ben Campbell In-Reply-To: <4CFD8731.9060208@KingsMountain.com> Date: Tue, 7 Dec 2010 19:35:35 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <49E7482C-83CF-4341-B6FA-F75E74038F8E@nostrum.com> References: <4CFD8731.9060208@KingsMountain.com> To: =JeffH X-Mailer: Apple Mail (2.1082) Received-SPF: pass (nostrum.com: 76.183.178.106 is authenticated by a trusted mechanism) X-Mailman-Approved-At: Tue, 07 Dec 2010 17:46:17 -0800 Cc: draft-saintandre-tls-server-id-check.all@tools.ietf.org, General Area Review Team , IETF cert-based identity Subject: Re: [certid] Gen-ART LC Review of draft-saintandre-tls-server-id-check-11 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, 08 Dec 2010 01:34:33 -0000 On Dec 6, 2010, at 7:00 PM, =3DJeffH wrote: > a followup on aspects of PeterSA's response.. >=20 >=20 > Peter Saint-Andre replied.. > > > > On 12/3/10 2:24 PM, "Ben Campbell" wrote: > > >=20 > thanks for the review. >=20 >=20 > >> -- 3.1, rule 3: > >> > >> What happens when you have multiple schemes that are defined to = refer to > >> the same resource. For example, SIP and SIPS? Does a SIP URI-ID = match an > >> otherwise identical SIPS URI-ID? (Maybe this should be left to the = URI > >> definitions themselves, but it might be worth mentioning the = complication > >> somewhere.) > > > > Given that a user agent would not connect to sip:example.com or > > http://example.com/ via SSL/TLS, it seems appropriate for the = certificate to > > include only the TLS-aware scheme (sips:, https:, etc.). >=20 > Yes, the latter seems appropriate, however RFC 5922 "Domain = Certificates in the Session Initiation Protocol (SIP)" seems to be = ambiguous (or maybe broken) on this point. Eg [S7.1] of RFC 5922 says in = part.. >=20 > 1. Examine each value in the subjectAltName field. ... Each > value in the subjectAltName has a type; the only types = acceptable > for encoding a SIP domain identity SHALL be: >=20 > URI If the scheme of the URI is not "sip", then the > implementation MUST NOT accept the value as a SIP domain > identity. >=20 > ... >=20 > DNS An implementation MUST accept a domain name system > identifier as a SIP domain identity if and only if no = other > identity is found that matches the "sip" URI type = described > above. >=20 >=20 > The above is saying that "sip:example.com" is what ought to be found = as a subjectAltName:uniformResourceIdentifier value -- note that it says = that one MUST NOT accept the cert if the URI scheme isn't "sip". Yes. See my comment to Peter's email. I _think_ the intent is that a SIP = user agent is going to look for a "sip" scheme in = subjectAltName:uniformResourceIdentifier, even the original URI that it = used to invoke a service had some other SIP compatible scheme (such as = SIPS or TEL). A side effect would be that you can't differentiate = between a service for SIP or SIPS using the certificate--and on = reflection, I think that's a good thing.=20 >=20 > Also, RFC 5626 "Client-Initiated Connections in SIP" > notes in [S4.3].. >=20 > ... For TLS protocols, there MUST = also > be a match between the host production in the next hop and one of = the > URIs contained in the subjectAltName in the peer certificate. ... >=20 > ..but doesn't say anything about the URI scheme. Right. By host production, I _think_ that is talking about what gets fed = into DNS. That is, the source domain in the parlance of the = tls-server-id-check. That is, not the URI itself. >=20 > And RFC 5630 "The Use of the SIPS URI Scheme in the Session Initiation = Protocol (SIP)" appears to not say anything about certificate validation = or name matching (it appears to punt to RFC 5626). >=20 > Finally, RFC 3261 -- the base SIP spec -- appears to only really = discuss S/MIME certs. >=20 > Are there other SIP RFCs we should also peruse? I think 5922 is the one most relevant for this effort. >=20 >=20 > >> -- 3.1, rule 5: "... unless a profile of this specification... " > >> > >> This pattern recurs throughout the document. Can you elaborate on = what you > >> mean by "profile"? Normally I think of a "profile" as defining a = subset > >> of choices for some particular application. But if a profile = relaxes a > >> requirement (i.e. encouraging something that is a SHOULD NOT here), = that's > >> not really a subset. Are you referring to an application protocol = spec > >> that refers to this document? Updates to this document? (I'm not = sure if > >> this should count as a minor issue or an editorial comment. It = depends on > >> whether its just a confusion around the word choice, or whether you = have > >> something specific in mind that I did not grok). > > > > I think it's a terminological issue. By "profile" we mean "a = specification > > that re-uses this one" -- as, say, draft-ietf-xmpp-3920bis re-uses = this I-D. > > The relationship is not one of defining a subset, but of being a = downstream > > customer. Is there a good, single word for that? If not, I think we = can say > > "Specifications that re-use this one" (ugly, but descriptive). >=20 > how about "normatively reference" rather than "re-use" ? WFM. Or "specs that depend...": >=20 >=20 >=20 > >> -- 3.1, rule 6: > >> > >> Can you motivate why this is not a MUST NOT? > > > > Jeff has better numbers on this than I do, but a non-trivial number = of > > existing certificates contain multiple CN-IDs. In addition, as long = as > > control over the domain names has been certified then folks on the = CertID > > list and other reviewers did not see harm in allowing CAs to include = those > > domain names in CN-ID form, although it's not encouraged to do that. >=20 >=20 > Rule 6 is.. >=20 > 6. The certificate MAY contain more than one DNS-ID, SRV-ID, or > URI-ID (but SHOULD NOT contain more than one CN-ID). >=20 >=20 > The reason for allowing this wiggle-room is that (for better or = worse).. >=20 > 1. the CA/Browser Forum Extended Validation (EV) Certificate = Guidelines > explicitly allow for multiple CN-IDs >=20 > 2. It's a not-totally-uncommon current practice to have certs that do = have > mutiple CN-IDs, eg from Comodo (whether EV or DV (domain = valivdated)). >=20 > 3. Virtual hosting multiple distinct-domain TLS servers on one entity = is > difficult today if one desires wide desktop client support because > a certain vendor's older-but-still-widely-deployed-OS does not = (yet?) > support the TLS Server Name Indication extension. Thus having one > cert with all the domains jammed in it (as either/both CN-IDs = or/and > DNS-IDs) is a workaround (eg Content Delivery Networks use this). >=20 >=20 > So some argue that if we MUST NOT multiple CN-IDs at this point, it is = flying in the face of present reality and might contribute to acquiring = an attained reputation for this BCP that is lower than we desire. >=20 > There is also concern on the part of CA folk about client-side TLS = libs and their support for name matching (ie some (old?) one(s) will = only match on CN-ID). >=20 > For a CA perspective on all the above, see... >=20 > Re: [certid] weird CN-IDs (subjectCommonName) in SSL Labs Survey Data > http://www.ietf.org/mail-archive/web/certid/current/msg00502.html I concur with Paul Hoffman's comment that putting a few words about that = in the draft would be helpful. >=20 >=20 >=20 > >> -- 3.2, first example: > >> > >> Since we say you SHOULD NOT put the FQDN in a CN-ID, why include it = in > >> examples? The example does seem to make sense, but it makes me = wonder if > >> the SHOULD NOT would be better placed on the client verification = process > >> not the cert generation process. > > > > I think it's better to delete that instance from the first example. >=20 > agreed. WFM >=20 >=20 >=20 >=20 > >> *** Nits/editorial comments: > >> > >> -- 1.1, paragraph 1: "...visible face of the Internet consists of = services > >> that employ a client-server architecture..." > >> > >> This seems a little overstated. Client-server applications are = certainly > >> common, but they don't represent all common uses of the Internet. = (Or do I > >> misinterpret what you mean by "visible face"?) > > > > You're right, "largely consists" is more accurate. >=20 > agreed. WFM >=20 >=20 > >> "references some conception... of... identity" > >> > >> I'm not sure what that means. Can you state this more plainly? = Maybe > >> "concept of identity" or "idea of identity"? (I realize = "conception" can > >> mean "concept", but it sounds strained to my mental ear.) > > > > How about "notion"? >=20 > "notion" sounds fine to me. WFM >=20 >=20 > >> -- 1.2, Paragraph 1: "document does not supersede the rules for > >> certificate issuance or validation provided in [PKIX]" > >> > >> If this document does not supercede PKIX, then that also means that = PKIX > >> is authoritative on any point for which is draft may be in conflict = with > >> it, right? > > > > Yes indeed. > > > >> "Specifically, in order to ensure proper authentication, = application > >> clients need to verify the entire certification path, because this > >> document addresses only name forms in the leaf server certificate, = not any > >> name forms in the chain of certificates used to validate the server > >> certificate." > >> > >> Sentence hard to parse. Can it be broken up or simplified? > > > > I think this is better: > > > > This document does not supersede the rules for certificate issuance = or > > validation provided in [PKIX]. Therefore, [PKIX] is authoritative = on any > > point that might also be discussed in this document. Furthermore, = [PKIX] > > also governs any certificate-related topic on which this document is = silent, > > such as certificate syntax, certificate extensions such as name = constraints > > and extended key usage, and handling of certification paths. > > > > This document addresses only name forms in the leaf server = certificate, not > > any name forms in the chain of certificates used to validate the = server > > certificate. Therefore, in order to ensure proper authentication, > > application clients need to verify the entire certification path. >=20 > looks good to me (LGTM) Works for me (WFM) >=20 >=20 >=20 > >> -- 1.5, definition of "subject name" > >> > >> Is there a definition or reference for "composite name"? > > > > Hmm, I don't see anything in RFC 5280, but I'll have to check the = X.5** > > specs. >=20 > "composite name" doesn't appear in the X.5?? specs AFAICT. >=20 > how about simply s/composite name/name/ ? WFM >=20 >=20 >=20 > >> -- 3.1, 1st paragraph: > >> > >> It's probably worth emphasizing that the rules are often = cumulative. I > >> think someone thinking about these for the first time might not = grasp that > >> until they see examples later in the doc. > > > > I've added the second sentence to this paragraph: > > > > When a certification authority issues a certificate based on the > > fully-qualified DNS domain name at which the application service = provider > > will provide the relevant application, the following rules apply to = the > > representation of application service identities. The reader needs = to be > > aware that some of these rules are cumulative and can interact in = important > > ways that are illustrated later in this document. >=20 > LGTM. WFM In fact, as I was re-reading RFC 5922, it occurred to me to wonder if = people need guidance one way or another on the idea of "multi-purpose" = certs that might have any number of subjectAltName entries for different = purposes. I'm talking about virtual domain hosting, or multi-protocol = hosts. I assume in the latter case, you would expect a host to use = different certs for different protocols. In the first case, is their any = guidance to give. I can't remember, do you mention the TLS server_name = extension? (I don't mean to suggest any real action here--just thinking out loud = about something that would have been much better to bring up well before = IETF LC. :-) ) >=20 >=20 >=20 > >> -- 4.3, 4th bullet item > >> > >> does the ABNF or URI reference define "reg-name" as well as = "scheme"? > > > > Yes. In the URI spec, "reg-name" is an FQDN, not an IP address or = mere host > > name. > > > >> That seems ambiguous. If not, then it might be helpful to have an > >> expansion, definition, or reference for "reg-name". > > > > Clarified as follows: > > > > o For a reference identifier of type URI-ID, the DNS domain name = portion is > > the "reg-name" part of the "authority" component and the application = type > > portion is the scheme name matching the [ABNF] "scheme" rule from = [URI] (not > > including the ':' separator); note that this document specifies that = a > > URI-ID always contains an "authority" component whose "host" = subcomponent > > contains a "reg- name" (matching only the "reg-name" rule from [URI] = limits > > verification to DNS domain names, differentiating a URI-ID from a > > uniformResourceIdentifier entry that contains an IP address or a = mere host > > name, or that does not contain an "authority" component), and that > > extraction of the "reg-name" might necessitate normalization of the = URI (as > > explained in [URI]). >=20 > LGTM. WFM >=20 >=20 > >> -- 4.4: "Furthermore, if the client supports presented identifiers = that > >> contain the wildcard character =B9*=B9, we define a supplemental = rule for > >> so-called "wildcard certificates". > >> > >> I think the definition will stay there regardless of the intent of = the > >> client :-) Perhaps something to the effect of "... We define a > >> supplemental rule...which may be used by clients that support = wildcards." > > > > Heh. Corrected to: > > > > Furthermore, to meet the needs of clients that support presented = identifiers > > containing the wildcard character '*', we define a supplemental rule = for > > so-called "wildcard certificates". >=20 > LGTM. WFM >=20 > thx again for your review, Thanks for considering it! Ben. From stpeter@stpeter.im Tue Dec 7 21:00:43 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1F253A6875; Tue, 7 Dec 2010 21:00:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.376 X-Spam-Level: X-Spam-Status: No, score=-102.376 tagged_above=-999 required=5 tests=[AWL=-0.377, BAYES_00=-2.599, J_CHICKENPOX_36=0.6, 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 dw4cA3+bDtkY; Tue, 7 Dec 2010 21:00:41 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 65B693A68C5; Tue, 7 Dec 2010 21:00:41 -0800 (PST) Received: from squire.local (ip-216-17-182-51.rev.frii.com [216.17.182.51]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 4C1BE4009B; Tue, 7 Dec 2010 22:13:55 -0700 (MST) Message-ID: <4CFF114B.5010204@stpeter.im> Date: Tue, 07 Dec 2010 22:02:03 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: Ben Campbell References: <4CFEB1C5.4010103@stpeter.im> In-Reply-To: X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms050106080106080504070603" Cc: draft-saintandre-tls-server-id-check.all@tools.ietf.org, General Area Review Team , certid@ietf.org Subject: Re: [certid] Gen-ART LC Review of draft-saintandre-tls-server-id-check-11 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, 08 Dec 2010 05:00:43 -0000 This is a cryptographically signed message in MIME format. --------------ms050106080106080504070603 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks, Ben. In general, I think this document is describing the tools available to protocol designers, not telling protocol designers which tools to use. More comments inline. On 12/7/10 5:10 PM, Ben Campbell wrote: > I'm jumping in a bit late with some review followup. It's not > entirely clear to me where in the thread I should re-insert myself, > so I apologize if I bring up stuff that would have been resolved or > otherwise obvious at other points in the thread--I'll dig back > through and respond further as appropriate. >=20 > (And I realize I'm doing lots of arm-waving around > whats-really-going-on with URI-IDs and SIP. If we need a higher > bandwidth communication, I can be available.) >=20 > Comments inline: >=20 > On Dec 7, 2010, at 4:14 PM, Peter Saint-Andre wrote: >=20 >> Hi Ben, I've looked again at the URI-ID issue, with special >> reference to SIP domain certs (RFC 5922) because SIP seems to be >> the main technology that uses URI-IDs. Some of what follows is me >> thinking out loud. I'll need to check any tentative conclusions >> with my co-author. >>=20 >> Also, please note that in this I-D Jeff and I have been working to=20 >> generalize from current practices. That's a bit difficult in the >> case of URI-IDs because we seem to have only one instance (RFC >> 5922). I'll ask the PKIX WG if folks are aware of any other >> "customers" for the uniformResourceIdentifier SAN. >>=20 >=20 > Understood. It may be that the answer is that the use of URI-ID is > not sufficiently understood to offer general guidance. OTOH, in the > case of SIP, the URI-ID appears to be solely for the purpose of > binding a domain name to the service. Otherwise, the use as defined > in RFC5922 would be substantially identical to using a DNS-ID. More > to the point, RFC5922 does not use URI-ID to specify a user identity, > only a host identity. Would you recommend designers of a new protocol > to follow that pattern?=20 Well, this document is about host ("application service") identity, so user identity is conveniently out of scope. > I note that (unless I missed it) the 5922 > doesn't seem to allow for falling back to a dNSName. Is that a > reasonable choice for a new protocol to make?=20 I think not. IMHO the fallback is a good idea. > (And doesn't this feel > a lot like using SRV-IDs?) Yes. > Now compare that to HTTP using a DNS-ID. The two are trying to > accomplish the same thing, in that they are identifying a domain > name, not a resource (in the case of HTTP) or a user (in the case of > SIP). Can we generalize anything from that? If we were starting over > with either, would we recommend HTTP use URI-ID, or perhaps SIP > should not? >=20 > I almost wonder if the best thing would be a discussion of what you > might could do with URI-ID, with very little normative stuff. If you > want to identify a host and service only, here's how.=20 Yes, and I think that's what our text is doing. Or trying to. > If you want to > identify something more like a resource, then do this other thing (or > say it''s out of scope). The latter. >> On 12/6/10 10:19 AM, Ben Campbell wrote: >>=20 >>> -- [ Not so much a "major issue" as a "slightly less minor" one] >>> I'd like to see more discussion around URI-IDs. These seem to me >>> to be the most complex ID type to get right, but there are no >>> examples and limited discussion. Picking on SIP, purely as an >>> example for which I have a passing familiarity: Would a SIP >>> reference identity match a SIPS URI-ID in a certificate? >>=20 >> RFC 5630 states: >>=20 >> SIP and SIPS URIs that are identical except for the scheme itself=20 >> (e.g., sip:alice@example.com and sips:alice@example.com) refer to >> the same resource. This requirement is implicit in [RFC3261], >> Section 19.1, which states that "any resource described by a SIP >> URI can be 'upgraded' to a SIPS URI by just changing the scheme, if >> it is desired to communicate with that resource securely". >>=20 >> So the two are interchangeable: a SIPS reference identity can be=20 >> compared against a SIP URI-ID and vice-versa. However, that >> equivalence is stipulated by the SIP specs and it is not something >> we could generalize to all uses of URI-IDs (say, http and https). >> And RFC 5922 says that the scheme of the presented identifier MUST >> be sip, not sips, so that's a further SIP-specific wrinkle. >=20 > Yeah, that's an interesting one. On reflection, I think RFC 5922 is, > again, trying to match _service_ more than a URI scheme. The service > is "sip" regardless of whether you started with a SIPS URI. When > you consider the further complication of TEL URIs (e.g. > tel:+18005551212), you're _still_ looking for a SIP service. This is > pretty much what I think you had in mind in the section 4.3 text on > URI_IDs, except that the service is implied by the fact that its a > SIP application in the first place, rather than simply copied from > some specific URI. >=20 > If this is the correct interpretation of 5922, then the SIPS/SIP > equivalence is probably a red herring. I'd certainly be interested > to hear the RFC 5922 author's thoughts on that. >=20 > For that matter, I think that XMPP and SIP both needed to accomplish > the same thing--match a source domain name and a service. Both > SRV-IDs and URI-IDs can do that, but they made opposite choices. I > suspect the choices were along the lines of "XMPP doesn't _use_ URIs, > and SIP does". But it doesn't seem like SIP is really matching > against a URI . And you could just as easily synthesize an XMPP > scheme and use URI-IDs--but the awkwardness becomes more obvious > there. Yes, we really care about the combination of DNS domain name and application type. That can be represented via SRV-IDs or URI-IDs. >>> Do I put both a URI-ID and an SRV-ID in my reference set and/or >>> certificate? >>=20 >> That depends. :) A using protocol needs to specify what identifier >> types are required and recommended for that application type. For >> example, in draft-ietf-xmpp-3920bis we've specified some guidelines >> for XMPP server certificates, but the guidelines used in the SIP or >> HTTP or IMAP community would be different (if those communities >> ever become "customers" of the server-id-check specification). >=20 > Right. But this document endeavors to recommend what people should > put in their specs for future protocols, right? Or does it just > discuss things they need to think about in their specs? I meant the > SIP questions as examples. They would probably been better stated as > "What should the new FUBAR protocol, which uses URIs and DNS in a way > functionally identical to SIP, do?" >=20 > The bottom line is, should this draft offer guidance on the best way > to match a source domain and service? Or is it to say "here's some > ways you can do it, pick one (or some)." I'm okay either way, but it > would be best to be explicit. I think we're saying "here's some ways you can do it, pick one" (either SRV-ID or URI-ID, with DNS-ID as a fallback). >>> How do I handle the fact that I sometimes need to do a NAPTR >>> query, before the SRV query depending on whether I know the >>> transport protocol? (I realize SIP already defines cert ID >>> matching, but what would I do for a new application protocol URI >>> with similar properties?) >>=20 >> I think you would take the input to the NAPTR lookup as the source=20 >> domain, just as you would for an SRV lookup or an A or AAAA >> lookup. Potentially there are more complexities in a NAPTR lookup >> (all that regex fun). Furthermore, the NAPTR result might lead the >> user agent to then perform an SRV lookup and then an A/AAAA lookup >> on the result of the SRV lookup (which is why I call it "the NAPTR >> three-step"). But I think that from the perspective of identity >> checking it doesn't make a difference how many steps are contained >> in the resolution process. See previous message. >=20 > I agree, that's the way it is supposed to work for SIP. Do you think > that it would be obvious to the hypothetical FUBAR designers whether > they should do the same? (I'm not saying it's not--I would need to > reread the draft with that in mind, and haven't done so yet.) This document says "if you use a SRV-ID (or URI-ID or DNS-ID), here's how to represent and verify it". >>> I wonder if the answer is that such things are scheme specific, >>> and that its hard to say much about the generic handling of >>> URI-IDs. >>=20 >> I think we can say that the client needs to separate the >> application type aspect of the URI-ID from the the DNS domain name >> aspect, and we do say that in Section 4.3: >>=20 >> ### >>=20 >> Before applying the comparison rules provided in the following=20 >> sections, the client might need to split the reference identifier=20 >> into its DNS domain name portion and its application type portion, >> as follows: >>=20 >> [...] >>=20 >> o For a reference identifier of type URI-ID, the DNS domain name=20 >> portion is the "reg-name" part of the "authority" component and the >> application type portion is the scheme name matching the [ABNF] >> "scheme" rule from [URI] (not including the ':' separator); note >> that this document specifies that a URI-ID always contains an=20 >> "authority" component whose "host" subcomponent contains a "reg-=20 >> name" (matching only the "reg-name" rule from [URI] limits=20 >> verification to DNS domain names, differentiating a URI-ID from a=20 >> uniformResourceIdentifier entry that contains an IP address or a=20 >> mere host name, or that does not contain an "authority" component), >> and that extraction of the "reg-name" might necessitate >> normalization of the URI (as explained in [URI]). >>=20 >> ### >>=20 >> The client then follows the rules for matching the DNS domain name=20 >> portion as specified in server-id-check document. So I think that >> the URI-ID type is not all that different from the others. >=20 > Is it your expectation that no protocol should try to include other, > more resourcey parts of a URI for the purposes of cert matching? Or > that that sort of thing should be out of scope? I think it should be out of scope. Let's imagine that the HTTP community decided to use URI-IDs. Even if the URI-ID in a certificate were http://www.example.com/foobar.html, a client would need to connect to the IP address resolved for www.example.com in order to retrieve foodar.html. Here again, it's the application service that matters. >> (There are complexities caused by URI normalization. I think it's >> best to point to RFC 3986 regarding such issues, rather than trying >> to describe them all in this spec.) >>=20 >>> If so, it might be worth mentioning that, and maybe discuss what >>> things the designer of a new scheme should keep in mind. >>=20 >> The designer of a new scheme, or the author of a specification >> that re-uses the recommendations in the server-id-check document? >=20 > The second, keeping in mine that new scheme design often happens as a > part of such an effort, even if the documents are split. (Would cert > matching be scheme specific, or protocol specific?) >=20 >>=20 >> If the former, I think that's a job for other documents >> (4395bis?). >>=20 >> If the latter, I don't particularly see that we can say much -- >> this is something that each technology community will need to >> consider, but really the only choices are: >>=20 >> 1. Which of CN-ID, DNS-ID, SRV-ID, and URI-ID do we recommend? >>=20 >> 2. Do we allow wildcards? If so, exactly where? >=20 > Recommendations about how to choose between DNS-ID, SRV-ID, and > URI-ID would be out of scope for this document, then, right? I think > that answers my previous question about how much the draft tries to > recommend. Yes, we were not thinking that this document would provide guidelines about how protocol designers would choose between identifier types. >>> -- 3.1, rule 3: >>>=20 >>> What happens when you have multiple schemes that are defined to >>> refer to the same resource. For example, SIP and SIPS? Does a >>> SIP URI-ID match an otherwise identical SIPS URI-ID? (Maybe this >>> should be left to the URI definitions themselves, but it might be >>> worth mentioning the complication somewhere.) >>=20 >> Right, so that is a third choice facing authors of specifications >> that re-use this one. I propose modifying the relevant paragraph in >> Section 3.1 as follows: >>=20 >> 3. If the service using the certificate deploys a technology in=20 >> which a server is typically associated with a URI (e.g., this is=20 >> true of [SIP]), then the certificate SHOULD include a URI-ID; the=20 >> scheme SHALL be that of the protocol associated with the service=20 >> type and the "authority" component SHALL be the fully-qualified DNS >> domain name of the service. A specification that re-uses this one >> MUST specify whether particular URI schemes are to be considered >> equivalent (e.g., http and https, or sip and sips as described in >> [RFC5630]). >=20 > Given the previous conversation about how SIP seems to be the only > protocol with the equivalent scheme issue that actually uses URI-IDs, > and that it doesn't seem to need to worry about which scheme its > using at the moment, I no longer think this draft needs to worry > about it. If it were to say anything at all along those lines, it > would probably need to be along the lines of KISS. For example, I > don't think you want designers trying to assert security properties > by which scheme they include in a cert (i.e. "foo" vs "foos") Well, I do think a using protocol does need to specify which URI scheme names are acceptable for the application protocol. You wouldn't want a client to think that fubar://example.com identifies a SIP service. The tel: URI scheme is an interesting counter-example in some ways. >> (But see below, where I propose further modifications to that >> paragraph to address another issue you've raised.) >>=20 >>> -- section 3.2: >>>=20 >>> I'd like to see a (non-trivial) URL-ID example. >>=20 >> How's this? >>=20 >> Consider a SIP-accessible voice-over-IP (VoIP) server at=20 >> "voice.example.edu" servicing SIP addresses of the form=20 >> "user@voice.example.edu" and located at a URI of=20 >> . A certificate for this service would >> include a URI-ID of "sip:voice.example.edu" (see [SIP-CERTS]). >>=20 >> Is that example "trivial", compared to the other examples in the >> spec? >=20 > No, I think that's a good one based on the discussion so far. > (assuming I am correct in my understanding that you don't expect to > ever see protocols match on user or resource information inside the > URI.) It might be worth mentioning in the example why the "user@" > part is not used. Because user@voice.example.edu is not an application service. :) >>> --4.2.1, paragraph 3: >>>=20 >>> It's probably out of scope, but it might be useful to offer some=20 >>> guidance on how ensuring the extraction is "not subject to=20 >>> subversion" is not always trivial. For example, if you got your >>> input URI by clicking on a link in a phishing email, that can be >>> almost isomorphic to using a delegation from a non-trusted >>> source. >>=20 >> I suggest modifying the relevant paragraph as follows (see the >> last sentence): >>=20 >> The client might need to extract the source domain and service >> type from the input(s) it has received. The extracted data MUST >> include only information that can be securely parsed out of the >> inputs (e.g., extracting the fully-qualified DNS domain name from >> the "authority" component of a URI or extracting the service type >> from the scheme of a URI) or information for which the extraction >> is performed in a manner that is not subject to subversion by >> network attackers (e.g., pulling the data from a delegated domain >> that is explicitly established via client or system configuration, >> resolving the data via [DNSSEC], or obtaining the data from a >> third-party domain mapping service in which a human user has >> explicitly placed trust and with which the client communicates over >> a connection that provides both mutual authentication and integrity >> checking). These considerations apply only to extraction of the >> source domain from the inputs; naturally, if the inputs themselves >> are invalid or corrupt (e.g., a user has clicked a link provided by >> a malicious entity in a phishing attack), then the client might end >> up communicating with an unexpected application service. >>=20 >=20 > WFM >=20 >>> -- 4.2.2: >>>=20 >>> Can we have a URI-ID example? >>=20 >> How's this? >>=20 >> A voice-over-IP (VoIP) user agent that is connecting via SIP to >> the voice service at "voice.example.edu" might have only one >> reference identifier: a URI-ID of "sip:voice.example.edu" (see >> [SIP-CERTS]). >>=20 >=20 > Would it make sense to say something to indicate this is true, even > though the connection may have been opened based on a URI of > "sip:user@voice.example.edu"? (I'm trying to figure out the best way > to word that without trying to invoke SIP request-URI vs route set > complexities, but my brain is tired. I will think further about it.) What do you mean by "the connection was opened based on a URI of sip:user@voice.example.edu"? Yes, the client might know that it is configured for an account with that URI, but in order to communicate with the application service it will need to resolve the DNS domain name (and application type) to an IP address. So that's the reference identifier. The presented identifier in the certificate will also be of the form sip:domain, not sip:user@domain. >>> (and maybe an explanation why the HTTP example doesn't use one?) >>=20 >> Well, we happen to know that no one does it that way. :) >>=20 >> However, we might need to tighten up the wording here: >>=20 >> 3. If the service using the certificate deploys a technology in=20 >> which a server is typically associated with a URI (e.g., this is=20 >> true of [SIP]), then the certificate SHOULD include a URI-ID.... >>=20 >> Specifically, we might need to say "programatically associated with >> a URI for security purposes" or somesuch. >>=20 >> This I-D is decidedly *not* attempting to modify how existing=20 >> technologies use PKIX certificates, so it would be improper for us >> to have a URI-ID example for HTTP. >=20 > Sure, the reason HTTP does not use is because HTTP isn't specified > that way :-) (i.e. for historical reasons.) Yep. :) >> I suggest the following tweaks: >>=20 >> 3. If the service using the certificate deploys a technology in=20 >> which a server is programatically associated with a URI for=20 >> security purposes (e.g., this is true of [SIP] as specified by=20 >> [SIP-CERTS]), but not true of [HTTP] since [HTTP-TLS] does not=20 >> describe usage of a URI-ID for HTTP services), then the certificate >> SHOULD include a URI-ID; the scheme SHALL be that of the protocol >> associated with the service type and the "authority" component >> SHALL be the fully-qualified DNS domain name of the service. A >> specification that re-uses this one MUST specify whether particular >> URI schemes are to be considered equivalent (e.g., http and https, >> or sip and sips as described in [SIP-SIPS]). >=20 > I think this is pretty close, modulo previous comments above. I > wonder if the fact that SIP appears to abstract the scheme rather > than use the scheme of any particular URI is relevant here, or just > adds too much complexity to the language. My first thought it that it adds too much complexity, but I'll consider it further tomorrow. >>> -- 4.3, 4th bullet item: >>>=20 >>> An example would be helpful here. >>=20 >> Yep, I propose that we add examples to all of those bullet points: >=20 > Ah, okay. I was mainly picking on URI-IDs due to the lack of examples > elsewhere. But more examples (almost) never hurt. >=20 >>=20 >> ### >>=20 >> Before applying the comparison rules provided in the following=20 >> sections, the client might need to split the reference identifier=20 >> into its DNS domain name portion and its application type portion, >> as follows: >>=20 >> o A reference identifier of type DNS-ID does not include an=20 >> application type portion and thus can be used directly as the DNS=20 >> domain name for comparison purposes. As an example, a DNS-ID of=20 >> "www.example.com" would result in a DNS domain name portion of=20 >> "www.example.com". >>=20 >> o A reference identifier of type CN-ID also does not include an=20 >> application type portion and thus can be used directly as the DNS=20 >> domain name for comparison purposes. As previously mentioned, this >> document specifies that a CN-ID always contains a string whose form >> matches that of a DNS domain name (thus differentiating a CN-ID >> from a Common Name containing a human-friendly name). >>=20 >> o For a reference identifier of type SRV-ID, the DNS domain name=20 >> portion is the Name and the application type portion is the=20 >> Service. As an example, an SRV-ID of "_imaps.mail.example.net"=20 >> would be split into a DNS domain name portion of "mail.example.net" >> and an application type portion of "imaps" (mapping to an >> application protocol of IMAP as explained in [EMAIL-SRV]). >>=20 >> o For a reference identifier of type URI-ID, the DNS domain name=20 >> portion is the "reg-name" part of the "authority" component and the >> application type portion is the scheme name matching the [ABNF] >> "scheme" rule from [URI] (not including the ':' separator). As >> previously mentioned, this document specifies that a URI-ID always >> contains an "authority" component whose "host" subcomponent=20 >> contains a "reg-name". (Matching only the "reg-name" rule from=20 >> [URI] limits verification to DNS domain names, thereby=20 >> differentiating a URI-ID from a uniformResourceIdentifier entry=20 >> that contains an IP address or a mere host name, or that does not=20 >> contain an "authority" component at all.). Furthermore, note that=20 >> extraction of the "reg-name" might necessitate normalization of the >> URI (as explained in [URI]. As an example, a URI-ID of "sip:=20 >> voice.example.edu" would be split into a DNS domain name portion of >> "voice.example.edu" and an application type of "sip" (mapping to an >> application protocol of SIP as explained in [SIP-CERTS]). ### >>=20 >> Again, those are all proposals. Ben, let us know if those address >> your questions. Jeff, let me know if you disagree with your >> co-author. :) Feedback is welcome on that text. Peter -- Peter Saint-Andre https://stpeter.im/ --------------ms050106080106080504070603 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/ jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q 7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo 98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR 6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV 0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD 0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri 2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6 wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1 nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2 gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1 My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo 6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3 GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6 2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4 TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0 ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+ 39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c 6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2 0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0 H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0 dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTIw ODA1MDIwM1owIwYJKoZIhvcNAQkEMRYEFDsX00TBNUxdZBXjli1n9RNiWVn+MF8GCSqGSIb3 DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG 9w0BAQEFAASCAQA+5g3CSo3zOAY2pjMz0JuGWqPst7cgb9S+RcK5Kqnwq9u2dASnfzKyTCU3 XTra3EizrT69tRwS1B45L9Th5G623ZlaHDEVIUesLjWhvE0Wq3Bhzz0v95Bdj/fe0MgecLnW 0ZwTEDZpXS2XxRSJ7EKPiWF8lMGBB5VNqEPSLa/JD+SnzIuYqi6tdCbRYxS75IwiC/n0HGGC K3sXPnTOmyH2FubqpsFNbv6n4INkElVBHNJweyyZb1HNQ7ZpsxC9w1P5kh7ztm+gLiGvi6no XESJ65JBdLF5Idvt0Q51Zjqu+bTdlnQkdDMKml5cpMreb2nO63rLtClYcbTQIt4pF1xSAAAA AAAA --------------ms050106080106080504070603-- From stpeter@stpeter.im Tue Dec 7 21:11:31 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D2583A689C; Tue, 7 Dec 2010 21:11:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.499 X-Spam-Level: X-Spam-Status: No, score=-101.499 tagged_above=-999 required=5 tests=[AWL=-1.200, BAYES_00=-2.599, MANGLED_LIST=2.3, 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 NJavhaisI+M0; Tue, 7 Dec 2010 21:11:25 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 7A2963A6875; Tue, 7 Dec 2010 21:11:22 -0800 (PST) Received: from squire.local (ip-216-17-182-51.rev.frii.com [216.17.182.51]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id ADBD54009B; Tue, 7 Dec 2010 22:24:37 -0700 (MST) Message-ID: <4CFF13C6.8090807@stpeter.im> Date: Tue, 07 Dec 2010 22:12:38 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: Ben Campbell References: <4CFD8731.9060208@KingsMountain.com> <49E7482C-83CF-4341-B6FA-F75E74038F8E@nostrum.com> In-Reply-To: <49E7482C-83CF-4341-B6FA-F75E74038F8E@nostrum.com> X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms080605030005080700010305" Cc: draft-saintandre-tls-server-id-check.all@tools.ietf.org, General Area Review Team , IETF cert-based identity , =JeffH Subject: Re: [certid] Gen-ART LC Review of draft-saintandre-tls-server-id-check-11 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, 08 Dec 2010 05:11:32 -0000 This is a cryptographically signed message in MIME format. --------------ms080605030005080700010305 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 12/7/10 6:35 PM, Ben Campbell wrote: >=20 > On Dec 6, 2010, at 7:00 PM, =3DJeffH wrote: >=20 >> Peter Saint-Andre replied.. >>>=20 >>> On 12/3/10 2:24 PM, "Ben Campbell" wrote: >>>> -- 3.1, 1st paragraph: >>>>=20 >>>> It's probably worth emphasizing that the rules are often >>>> cumulative. I think someone thinking about these for the first >>>> time might not grasp that until they see examples later in the >>>> doc. >>>=20 >>> I've added the second sentence to this paragraph: >>>=20 >>> When a certification authority issues a certificate based on the=20 >>> fully-qualified DNS domain name at which the application service >>> provider will provide the relevant application, the following >>> rules apply to the representation of application service >>> identities. The reader needs to be aware that some of these >>> rules are cumulative and can interact in important ways that are >>> illustrated later in this document. >>=20 >> LGTM. >=20 > WFM >=20 > In fact, as I was re-reading RFC 5922, it occurred to me to wonder if > people need guidance one way or another on the idea of > "multi-purpose" certs that might have any number of subjectAltName > entries for different purposes. I'm talking about virtual domain > hosting, or multi-protocol hosts. I assume in the latter case, you > would expect a host to use different certs for different protocols. > In the first case, is their any guidance to give. I can't remember, > do you mention the TLS server_name extension? >=20 > (I don't mean to suggest any real action here--just thinking out loud > about something that would have been much better to bring up well > before IETF LC. :-) ) Those scenarios are important, but IMHO how the server determines which certificate to present (e.g., based on the SNI or something else, such as the 'to' address on an XMPP stream header) is something that an application protocol specification needs to define. Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms080605030005080700010305 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/ jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q 7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo 98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR 6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV 0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD 0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri 2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6 wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1 nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2 gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1 My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo 6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3 GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6 2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4 TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0 ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+ 39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c 6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2 0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0 H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0 dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTIw ODA1MTIzOFowIwYJKoZIhvcNAQkEMRYEFEPHjlXgaJWcZrO6TlH9n0xcP+acMF8GCSqGSIb3 DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG 9w0BAQEFAASCAQAV587RPVQAk1Jw75czSRZySVd7YU5STvBv9AKPcEZhTEEd+j67hR6RRJWO DZa7ndQqlQhTF88EK8sPZuWheuUpemn4hObjQg/ZUcjRlMa+N7C0v6khFihqEF2Cd6oG5zl5 sBWUCUJ4qtPJMaoqHLzBRXHS3bY1fUcZFR1crlOud8vYEribrKEHv9wQl+2RnmdubqbIx5uO 9nq12LmJIc2SLq1bhXKU7qSy8bFq5iXwm0yx0Gm3pAphsz49GVkjwy8qQk03V/Pk8S6uQweT uVtvM+7zkMmh0AKpp4CRcGHHRY+GZ2crjOJrGll+yoPeh/p3uDFJVTfZQ2WwY1Nxit+hAAAA AAAA --------------ms080605030005080700010305-- From ben@nostrum.com Tue Dec 7 21:42: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 9CFAB3A68D3; Tue, 7 Dec 2010 21:42:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.976 X-Spam-Level: X-Spam-Status: No, score=-101.976 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, J_CHICKENPOX_36=0.6, SPF_PASS=-0.001, 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 1PG3PVvHO08k; Tue, 7 Dec 2010 21:42:43 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 57F2E3A68C5; Tue, 7 Dec 2010 21:42:42 -0800 (PST) Received: from [10.0.1.6] (cpe-76-183-178-106.tx.res.rr.com [76.183.178.106]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id oB85i7Xh096798 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 7 Dec 2010 23:44:07 -0600 (CST) (envelope-from ben@nostrum.com) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Ben Campbell In-Reply-To: <4CFF114B.5010204@stpeter.im> Date: Tue, 7 Dec 2010 23:44:07 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <19F8341D-9815-4BB7-8837-83850FAC4F9E@nostrum.com> References: <4CFEB1C5.4010103@stpeter.im> <4CFF114B.5010204@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1082) Received-SPF: pass (nostrum.com: 76.183.178.106 is authenticated by a trusted mechanism) Cc: draft-saintandre-tls-server-id-check.all@tools.ietf.org, General Area Review Team , certid@ietf.org Subject: Re: [certid] [Gen-art] Gen-ART LC Review of draft-saintandre-tls-server-id-check-11 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, 08 Dec 2010 05:42:46 -0000 On Dec 7, 2010, at 11:02 PM, Peter Saint-Andre wrote: > Thanks, Ben. >=20 > In general, I think this document is describing the tools available to > protocol designers, not telling protocol designers which tools to use. Okay, then :-) On re-reading the thread, I realize I did a lot of dead-horse beating. = Further comments below, with the areas I think we are in agreement = elided.=20 >=20 > More comments inline. >=20 > On 12/7/10 5:10 PM, Ben Campbell wrote: >> I'm jumping in a bit late with some review followup. It's not >> entirely clear to me where in the thread I should re-insert myself, >> so I apologize if I bring up stuff that would have been resolved or >> otherwise obvious at other points in the thread--I'll dig back >> through and respond further as appropriate. >>=20 >> (And I realize I'm doing lots of arm-waving around >> whats-really-going-on with URI-IDs and SIP. If we need a higher >> bandwidth communication, I can be available.) >>=20 >> Comments inline: >>=20 >> On Dec 7, 2010, at 4:14 PM, Peter Saint-Andre wrote: >>=20 [...] >>=20 >> Understood. It may be that the answer is that the use of URI-ID is >> not sufficiently understood to offer general guidance. OTOH, in the >> case of SIP, the URI-ID appears to be solely for the purpose of >> binding a domain name to the service. Otherwise, the use as defined >> in RFC5922 would be substantially identical to using a DNS-ID. More >> to the point, RFC5922 does not use URI-ID to specify a user identity, >> only a host identity. Would you recommend designers of a new protocol >> to follow that pattern?=20 >=20 > Well, this document is about host ("application service") identity, so > user identity is conveniently out of scope. >=20 Okay >> I note that (unless I missed it) the 5922 >> doesn't seem to allow for falling back to a dNSName. Is that a >> reasonable choice for a new protocol to make?=20 >=20 > I think not. IMHO the fallback is a good idea. But, from previous comments, such guidance does not belong in this = draft, right? [...] >> Given the previous conversation about how SIP seems to be the only >> protocol with the equivalent scheme issue that actually uses URI-IDs, >> and that it doesn't seem to need to worry about which scheme its >> using at the moment, I no longer think this draft needs to worry >> about it. If it were to say anything at all along those lines, it >> would probably need to be along the lines of KISS. For example, I >> don't think you want designers trying to assert security properties >> by which scheme they include in a cert (i.e. "foo" vs "foos") >=20 > Well, I do think a using protocol does need to specify which URI = scheme > names are acceptable for the application protocol. You wouldn't want a > client to think that fubar://example.com identifies a SIP service. The > tel: URI scheme is an interesting counter-example in some ways. >=20 Not to mention "im:" and "pres:" :-) Am I correct in assuming you mean that in the context of what schemes = they will put in a certificate, or match to a certificate, right? As = opposed to what schemes are legal in the application protocol as a = whole--since these are probably somewhat separate dimensions of = extensibility. (If the second, then I'm in over my depth in = meta-protocol design, and would certainly defer to an apps area expert = if one were handy ;-) ) [...] >>>> -- 4.2.2: >>>>=20 >>>> Can we have a URI-ID example? >>>=20 >>> How's this? >>>=20 >>> A voice-over-IP (VoIP) user agent that is connecting via SIP to >>> the voice service at "voice.example.edu" might have only one >>> reference identifier: a URI-ID of "sip:voice.example.edu" (see >>> [SIP-CERTS]). >>>=20 >>=20 >> Would it make sense to say something to indicate this is true, even >> though the connection may have been opened based on a URI of >> "sip:user@voice.example.edu"? (I'm trying to figure out the best way >> to word that without trying to invoke SIP request-URI vs route set >> complexities, but my brain is tired. I will think further about it.) >=20 > What do you mean by "the connection was opened based on a URI of > sip:user@voice.example.edu"? Yes, the client might know that it is > configured for an account with that URI, but in order to communicate > with the application service it will need to resolve the DNS domain = name > (and application type) to an IP address. So that's the reference > identifier. The presented identifier in the certificate will also be = of > the form sip:domain, not sip:user@domain. >=20 Sure, and I guess what I am talking about is how one derives a reference = identifier of sip:voice.example.edu from an address of record (AoR) of = sip:user@voice.example.edu. For example, I click on the AoR on a web = page, or I type it from Mr. User's business card. I guess my point is it = would be useful for the example to show that, given the URI of a = _resource_, you derive (extract?) a URI of a _service_ to be the = reference entry. You've mentioned that in text, but it would be useful = for the example to show it as well. [...] >=20 >>> I suggest the following tweaks: >>>=20 >>> 3. If the service using the certificate deploys a technology in=20 >>> which a server is programatically associated with a URI for=20 >>> security purposes (e.g., this is true of [SIP] as specified by=20 >>> [SIP-CERTS]), but not true of [HTTP] since [HTTP-TLS] does not=20 >>> describe usage of a URI-ID for HTTP services), then the certificate >>> SHOULD include a URI-ID; the scheme SHALL be that of the protocol >>> associated with the service type and the "authority" component >>> SHALL be the fully-qualified DNS domain name of the service. A >>> specification that re-uses this one MUST specify whether particular >>> URI schemes are to be considered equivalent (e.g., http and https, >>> or sip and sips as described in [SIP-SIPS]). >>=20 >> I think this is pretty close, modulo previous comments above. I >> wonder if the fact that SIP appears to abstract the scheme rather >> than use the scheme of any particular URI is relevant here, or just >> adds too much complexity to the language. >=20 > My first thought it that it adds too much complexity, but I'll = consider > it further tomorrow. >=20 Okay. I can't off-hand think of a simple way to put it, so you are = probably right.=20 [...] From ben@nostrum.com Tue Dec 7 21:44:33 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 CAABB3A68C5; Tue, 7 Dec 2010 21:44:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.127 X-Spam-Level: X-Spam-Status: No, score=-101.127 tagged_above=-999 required=5 tests=[AWL=-0.827, BAYES_00=-2.599, MANGLED_LIST=2.3, SPF_PASS=-0.001, 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 5hkEogdPydgh; Tue, 7 Dec 2010 21:44:31 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 464723A689C; Tue, 7 Dec 2010 21:44:31 -0800 (PST) Received: from [10.0.1.6] (cpe-76-183-178-106.tx.res.rr.com [76.183.178.106]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id oB85joBG096934 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 7 Dec 2010 23:45:55 -0600 (CST) (envelope-from ben@nostrum.com) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Ben Campbell In-Reply-To: <4CFF13C6.8090807@stpeter.im> Date: Tue, 7 Dec 2010 23:45:50 -0600 Content-Transfer-Encoding: 7bit Message-Id: <0BEA063A-8BC5-4292-8F7D-79588E7256EA@nostrum.com> References: <4CFD8731.9060208@KingsMountain.com> <49E7482C-83CF-4341-B6FA-F75E74038F8E@nostrum.com> <4CFF13C6.8090807@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1082) Received-SPF: pass (nostrum.com: 76.183.178.106 is authenticated by a trusted mechanism) Cc: draft-saintandre-tls-server-id-check.all@tools.ietf.org, General Area Review Team , IETF cert-based identity , =JeffH Subject: Re: [certid] [Gen-art] Gen-ART LC Review of draft-saintandre-tls-server-id-check-11 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, 08 Dec 2010 05:44:34 -0000 On Dec 7, 2010, at 11:12 PM, Peter Saint-Andre wrote: > On 12/7/10 6:35 PM, Ben Campbell wrote: >> >> On Dec 6, 2010, at 7:00 PM, =JeffH wrote: >> >>> Peter Saint-Andre replied.. >>>> >>>> On 12/3/10 2:24 PM, "Ben Campbell" wrote: > > > >>>>> -- 3.1, 1st paragraph: >>>>> >>>>> It's probably worth emphasizing that the rules are often >>>>> cumulative. I think someone thinking about these for the first >>>>> time might not grasp that until they see examples later in the >>>>> doc. >>>> >>>> I've added the second sentence to this paragraph: >>>> >>>> When a certification authority issues a certificate based on the >>>> fully-qualified DNS domain name at which the application service >>>> provider will provide the relevant application, the following >>>> rules apply to the representation of application service >>>> identities. The reader needs to be aware that some of these >>>> rules are cumulative and can interact in important ways that are >>>> illustrated later in this document. >>> >>> LGTM. >> >> WFM >> >> In fact, as I was re-reading RFC 5922, it occurred to me to wonder if >> people need guidance one way or another on the idea of >> "multi-purpose" certs that might have any number of subjectAltName >> entries for different purposes. I'm talking about virtual domain >> hosting, or multi-protocol hosts. I assume in the latter case, you >> would expect a host to use different certs for different protocols. >> In the first case, is their any guidance to give. I can't remember, >> do you mention the TLS server_name extension? >> >> (I don't mean to suggest any real action here--just thinking out loud >> about something that would have been much better to bring up well >> before IETF LC. :-) ) > > Those scenarios are important, but IMHO how the server determines which > certificate to present (e.g., based on the SNI or something else, such > as the 'to' address on an XMPP stream header) is something that an > application protocol specification needs to define. Agreed. Does this draft need to say that, or do we just take it as given? > > Peter > > -- > Peter Saint-Andre > https://stpeter.im/ > > > > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art From stpeter@stpeter.im Wed Dec 8 05:09: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 298CB3A6938; Wed, 8 Dec 2010 05:09:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.419 X-Spam-Level: X-Spam-Status: No, score=-101.419 tagged_above=-999 required=5 tests=[AWL=-1.120, BAYES_00=-2.599, MANGLED_LIST=2.3, 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 fvtFFYdDwmx8; Wed, 8 Dec 2010 05:09:34 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 0EAF23A680C; Wed, 8 Dec 2010 05:09:33 -0800 (PST) Received: from squire.local (ip-216-17-182-51.rev.frii.com [216.17.182.51]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 333724009B; Wed, 8 Dec 2010 06:22:51 -0700 (MST) Message-ID: <4CFF83E3.9020909@stpeter.im> Date: Wed, 08 Dec 2010 06:10:59 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: Ben Campbell References: <4CFD8731.9060208@KingsMountain.com> <49E7482C-83CF-4341-B6FA-F75E74038F8E@nostrum.com> <4CFF13C6.8090807@stpeter.im> <0BEA063A-8BC5-4292-8F7D-79588E7256EA@nostrum.com> In-Reply-To: <0BEA063A-8BC5-4292-8F7D-79588E7256EA@nostrum.com> X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms080501010905040301060605" Cc: draft-saintandre-tls-server-id-check.all@tools.ietf.org, General Area Review Team , IETF cert-based identity , =JeffH Subject: Re: [certid] [Gen-art] Gen-ART LC Review of draft-saintandre-tls-server-id-check-11 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, 08 Dec 2010 13:09:35 -0000 This is a cryptographically signed message in MIME format. --------------ms080501010905040301060605 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 12/7/10 10:45 PM, Ben Campbell wrote: >=20 > On Dec 7, 2010, at 11:12 PM, Peter Saint-Andre wrote: >=20 >> On 12/7/10 6:35 PM, Ben Campbell wrote: >>> >>> On Dec 6, 2010, at 7:00 PM, =3DJeffH wrote: >>> >>>> Peter Saint-Andre replied.. >>>>> >>>>> On 12/3/10 2:24 PM, "Ben Campbell" wrote: >> >> >> >>>>>> -- 3.1, 1st paragraph: >>>>>> >>>>>> It's probably worth emphasizing that the rules are often >>>>>> cumulative. I think someone thinking about these for the first >>>>>> time might not grasp that until they see examples later in the >>>>>> doc. >>>>> >>>>> I've added the second sentence to this paragraph: >>>>> >>>>> When a certification authority issues a certificate based on the=20 >>>>> fully-qualified DNS domain name at which the application service >>>>> provider will provide the relevant application, the following >>>>> rules apply to the representation of application service >>>>> identities. The reader needs to be aware that some of these >>>>> rules are cumulative and can interact in important ways that are >>>>> illustrated later in this document. >>>> >>>> LGTM. >>> >>> WFM >>> >>> In fact, as I was re-reading RFC 5922, it occurred to me to wonder if= >>> people need guidance one way or another on the idea of >>> "multi-purpose" certs that might have any number of subjectAltName >>> entries for different purposes. I'm talking about virtual domain >>> hosting, or multi-protocol hosts. I assume in the latter case, you >>> would expect a host to use different certs for different protocols. >>> In the first case, is their any guidance to give. I can't remember, >>> do you mention the TLS server_name extension? >>> >>> (I don't mean to suggest any real action here--just thinking out loud= >>> about something that would have been much better to bring up well >>> before IETF LC. :-) ) >> >> Those scenarios are important, but IMHO how the server determines whic= h >> certificate to present (e.g., based on the SNI or something else, such= >> as the 'to' address on an XMPP stream header) is something that an >> application protocol specification needs to define. >=20 > Agreed. Does this draft need to say that, or do we just take it as give= n? I think it's appropriate to add a few words about that. I suggest... 1.1 ... When a client connects to an application service using Transport Layer Security [TLS] or Datagram Transport Layer Security [DTLS], it references some notion of the server's identity while attempting to establish a secure connection (e.g., "the website at example.com") and typically specifies at least the DNS domain name with which it is trying to communicate (e.g., using a Server Name Indication during TLS negotiation as described in [TLS-EXT]). 1.5 presented identifier: An identifier that is presented by a server to a client within a PKIX certificate when the client attempts to establish a secure connection with the server; the certificate can include one or more presented identifiers of different types, and the certificate presented is typically based on a DNS domain name specified by the client when initiating communication (e.g., using a Server Name Indication during TLS negotiation as described in [TLS-EXT]). Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms080501010905040301060605 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/ jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q 7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo 98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR 6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV 0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD 0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri 2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6 wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1 nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2 gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1 My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo 6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3 GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6 2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4 TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0 ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+ 39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c 6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2 0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0 H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0 dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTIw ODEzMTA1OVowIwYJKoZIhvcNAQkEMRYEFCJcagvwzP0+TmYiThhZ81Jr8tlbMF8GCSqGSIb3 DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG 9w0BAQEFAASCAQAYLiX1jNfSdvldVKipvPdGZFZhuAbsgZ5df9KvbcZq+ZZwkySm5nClm3vb Lp1uq9dPnVyMPyg3DJIG3ZSsfwSasIIptQqMVx5hF69uhJj2DaSzUWTmwJZhwJVNg/juomYS 4ozyqYY0aoUXLZ8X+Rl4/dyydbHXjeURtG/epmdUoghQioJKBfmV7Yc8w5sCVSKafNtE+U8/ AUkGHph9k/znDtLvihvmMN6jbMLYz68G20+uhSb9hyuOyquHTi06bgirwTu0tY5+2z72YRoc eA7FY5aTtmV5WSKw/d5bili/JNMnJ1wvYAJSFBDIGaamgn6d2lTfuXhFQmKx33K/wpoLAAAA AAAA --------------ms080501010905040301060605-- From ben@nostrum.com Wed Dec 8 06:35: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 C7BCC3A6783; Wed, 8 Dec 2010 06:35:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.378 X-Spam-Level: X-Spam-Status: No, score=-100.378 tagged_above=-999 required=5 tests=[AWL=-1.474, BAYES_00=-2.599, MANGLED_LIST=2.3, MIME_QP_LONG_LINE=1.396, SPF_PASS=-0.001, 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 wj7uHIyEH9Dc; Wed, 8 Dec 2010 06:35:47 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 1DB313A67F7; Wed, 8 Dec 2010 06:35:46 -0800 (PST) Received: from [10.0.1.12] (cpe-76-183-178-106.tx.res.rr.com [76.183.178.106]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id oB8EbBHt042804 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 8 Dec 2010 08:37:13 -0600 (CST) (envelope-from ben@nostrum.com) References: <4CFD8731.9060208@KingsMountain.com> <49E7482C-83CF-4341-B6FA-F75E74038F8E@nostrum.com> <4CFF13C6.8090807@stpeter.im> <0BEA063A-8BC5-4292-8F7D-79588E7256EA@nostrum.com> <4CFF83E3.9020909@stpeter.im> In-Reply-To: <4CFF83E3.9020909@stpeter.im> Mime-Version: 1.0 (iPad Mail 8C148) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <81E25826-55C1-4D70-9582-CA428C93908E@nostrum.com> X-Mailer: iPad Mail (8C148) From: Ben Campbell Date: Wed, 8 Dec 2010 08:37:10 -0600 To: Peter Saint-Andre Received-SPF: pass (nostrum.com: 76.183.178.106 is authenticated by a trusted mechanism) Cc: "draft-saintandre-tls-server-id-check.all@tools.ietf.org" , General Area Review Team , IETF cert-based identity , =JeffH Subject: Re: [certid] [Gen-art] Gen-ART LC Review of draft-saintandre-tls-server-id-check-11 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, 08 Dec 2010 14:35:49 -0000 On Dec 8, 2010, at 7:10 AM, Peter Saint-Andre wrote: > On 12/7/10 10:45 PM, Ben Campbell wrote: >>=20 >> On Dec 7, 2010, at 11:12 PM, Peter Saint-Andre wrote: >>=20 >>> On 12/7/10 6:35 PM, Ben Campbell wrote: >>>>=20 >>>> On Dec 6, 2010, at 7:00 PM, =3DJeffH wrote: >>>>=20 >>>>> Peter Saint-Andre replied.. >>>>>>=20 >>>>>> On 12/3/10 2:24 PM, "Ben Campbell" wrote: >>>=20 >>> >>>=20 >>>>>>> -- 3.1, 1st paragraph: >>>>>>>=20 >>>>>>> It's probably worth emphasizing that the rules are often >>>>>>> cumulative. I think someone thinking about these for the first >>>>>>> time might not grasp that until they see examples later in the >>>>>>> doc. >>>>>>=20 >>>>>> I've added the second sentence to this paragraph: >>>>>>=20 >>>>>> When a certification authority issues a certificate based on the=20 >>>>>> fully-qualified DNS domain name at which the application service >>>>>> provider will provide the relevant application, the following >>>>>> rules apply to the representation of application service >>>>>> identities. The reader needs to be aware that some of these >>>>>> rules are cumulative and can interact in important ways that are >>>>>> illustrated later in this document. >>>>>=20 >>>>> LGTM. >>>>=20 >>>> WFM >>>>=20 >>>> In fact, as I was re-reading RFC 5922, it occurred to me to wonder if >>>> people need guidance one way or another on the idea of >>>> "multi-purpose" certs that might have any number of subjectAltName >>>> entries for different purposes. I'm talking about virtual domain >>>> hosting, or multi-protocol hosts. I assume in the latter case, you >>>> would expect a host to use different certs for different protocols. >>>> In the first case, is their any guidance to give. I can't remember, >>>> do you mention the TLS server_name extension? >>>>=20 >>>> (I don't mean to suggest any real action here--just thinking out loud >>>> about something that would have been much better to bring up well >>>> before IETF LC. :-) ) >>>=20 >>> Those scenarios are important, but IMHO how the server determines which >>> certificate to present (e.g., based on the SNI or something else, such >>> as the 'to' address on an XMPP stream header) is something that an >>> application protocol specification needs to define. >>=20 >> Agreed. Does this draft need to say that, or do we just take it as given?= >=20 > I think it's appropriate to add a few words about that. I suggest... >=20 > 1.1 >=20 > ... When a client connects to an > application service using Transport Layer Security [TLS] or Datagram > Transport Layer Security [DTLS], it references some notion of the > server's identity while attempting to establish a secure connection > (e.g., "the website at example.com") and typically specifies at least > the DNS domain name with which it is trying to communicate (e.g., > using a Server Name Indication during TLS negotiation as described in > [TLS-EXT]). >=20 > 1.5 >=20 > presented identifier: An identifier that is presented by a server to > a client within a PKIX certificate when the client attempts to > establish a secure connection with the server; the certificate can > include one or more presented identifiers of different types, and > the certificate presented is typically based on a DNS domain name > specified by the client when initiating communication (e.g., using > a Server Name Indication during TLS negotiation as described in > [TLS-EXT]). >=20 Do you think server_name extension use is actually common enough to call typ= ical? I'm not saying it's not--I don't really know one way or another. Other= wise, WFM. > Peter >=20 > --=20 > Peter Saint-Andre > https://stpeter.im/ >=20 >=20 >=20 From stpeter@stpeter.im Wed Dec 8 06:53:49 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5BFB83A6956; Wed, 8 Dec 2010 06:53:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.449 X-Spam-Level: X-Spam-Status: No, score=-101.449 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, MANGLED_LIST=2.3, 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 NWuN05z+IYOl; Wed, 8 Dec 2010 06:53:26 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id A23EE3A67ED; Wed, 8 Dec 2010 06:53:26 -0800 (PST) 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 603874009B; Wed, 8 Dec 2010 08:06:44 -0700 (MST) Message-ID: <4CFF9C3C.4040906@stpeter.im> Date: Wed, 08 Dec 2010 07:54:52 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: Ben Campbell References: <4CFD8731.9060208@KingsMountain.com> <49E7482C-83CF-4341-B6FA-F75E74038F8E@nostrum.com> <4CFF13C6.8090807@stpeter.im> <0BEA063A-8BC5-4292-8F7D-79588E7256EA@nostrum.com> <4CFF83E3.9020909@stpeter.im> <81E25826-55C1-4D70-9582-CA428C93908E@nostrum.com> In-Reply-To: <81E25826-55C1-4D70-9582-CA428C93908E@nostrum.com> X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms060201050204070504040902" Cc: "draft-saintandre-tls-server-id-check.all@tools.ietf.org" , General Area Review Team , IETF cert-based identity , =JeffH Subject: Re: [certid] [Gen-art] Gen-ART LC Review of draft-saintandre-tls-server-id-check-11 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, 08 Dec 2010 14:53:49 -0000 This is a cryptographically signed message in MIME format. --------------ms060201050204070504040902 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 12/8/10 7:37 AM, Ben Campbell wrote: >=20 >=20 > On Dec 8, 2010, at 7:10 AM, Peter Saint-Andre > wrote: >=20 >> On 12/7/10 10:45 PM, Ben Campbell wrote: >>>=20 >>> On Dec 7, 2010, at 11:12 PM, Peter Saint-Andre wrote: >>>=20 >>>> On 12/7/10 6:35 PM, Ben Campbell wrote: >>>>>=20 >>>>> On Dec 6, 2010, at 7:00 PM, =3DJeffH wrote: >>>>>=20 >>>>>> Peter Saint-Andre replied.. >>>>>>>=20 >>>>>>> On 12/3/10 2:24 PM, "Ben Campbell" >>>>>>> wrote: >>>>=20 >>>> >>>>=20 >>>>>>>> -- 3.1, 1st paragraph: >>>>>>>>=20 >>>>>>>> It's probably worth emphasizing that the rules are >>>>>>>> often cumulative. I think someone thinking about these >>>>>>>> for the first time might not grasp that until they see >>>>>>>> examples later in the doc. >>>>>>>=20 >>>>>>> I've added the second sentence to this paragraph: >>>>>>>=20 >>>>>>> When a certification authority issues a certificate based >>>>>>> on the fully-qualified DNS domain name at which the >>>>>>> application service provider will provide the relevant >>>>>>> application, the following rules apply to the >>>>>>> representation of application service identities. The >>>>>>> reader needs to be aware that some of these rules are >>>>>>> cumulative and can interact in important ways that are=20 >>>>>>> illustrated later in this document. >>>>>>=20 >>>>>> LGTM. >>>>>=20 >>>>> WFM >>>>>=20 >>>>> In fact, as I was re-reading RFC 5922, it occurred to me to >>>>> wonder if people need guidance one way or another on the idea >>>>> of "multi-purpose" certs that might have any number of >>>>> subjectAltName entries for different purposes. I'm talking >>>>> about virtual domain hosting, or multi-protocol hosts. I >>>>> assume in the latter case, you would expect a host to use >>>>> different certs for different protocols. In the first case, >>>>> is their any guidance to give. I can't remember, do you >>>>> mention the TLS server_name extension? >>>>>=20 >>>>> (I don't mean to suggest any real action here--just thinking >>>>> out loud about something that would have been much better to >>>>> bring up well before IETF LC. :-) ) >>>>=20 >>>> Those scenarios are important, but IMHO how the server >>>> determines which certificate to present (e.g., based on the SNI >>>> or something else, such as the 'to' address on an XMPP stream >>>> header) is something that an application protocol specification >>>> needs to define. >>>=20 >>> Agreed. Does this draft need to say that, or do we just take it >>> as given? >>=20 >> I think it's appropriate to add a few words about that. I >> suggest... >>=20 >> 1.1 >>=20 >> ... When a client connects to an application service using >> Transport Layer Security [TLS] or Datagram Transport Layer Security >> [DTLS], it references some notion of the server's identity while >> attempting to establish a secure connection (e.g., "the website at >> example.com") and typically specifies at least the DNS domain name >> with which it is trying to communicate (e.g., using a Server Name >> Indication during TLS negotiation as described in [TLS-EXT]). >>=20 >> 1.5 >>=20 >> presented identifier: An identifier that is presented by a server >> to a client within a PKIX certificate when the client attempts to=20 >> establish a secure connection with the server; the certificate can=20 >> include one or more presented identifiers of different types, and=20 >> the certificate presented is typically based on a DNS domain name=20 >> specified by the client when initiating communication (e.g., using=20 >> a Server Name Indication during TLS negotiation as described in=20 >> [TLS-EXT]). >>=20 >=20 > Do you think server_name extension use is actually common enough to > call typical? I'm not saying it's not--I don't really know one way or > another. Otherwise, WFM. We could say "and if the server hosts more than one domain then the certificate presented is typically based..." Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms060201050204070504040902 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/ jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q 7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo 98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR 6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV 0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD 0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri 2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6 wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1 nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2 gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1 My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo 6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3 GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6 2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4 TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0 ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+ 39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c 6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2 0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0 H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0 dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTIw ODE0NTQ1MlowIwYJKoZIhvcNAQkEMRYEFC7l0Qu1UxwM0K4zpSN2Tgp2WrxzMF8GCSqGSIb3 DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG 9w0BAQEFAASCAQBONX7PXlWLE84355XlYebC3iGuANsio8xzTKlQkJeb9VLDckjxXMi45el/ wHy0lyJDsZyHtn1N1i/uWw0MZyg9FXSgJrZ7xBU3mtxe87ZDqCAlXPNSZP4nASc2LsbT25Gn 52zfHaufJnITcSIhOT2GXaWeiOmtRRBkbjM5dbFTxZdJTYxFCjg9kYDgVnvkjJeH0PyWocAT o03GbVrEOMRNNVkiswV0UvP+u9w5EJAztCL0ABRQYDFYLckuDLQOpgBJxZW3QM1w851ccahz iW0UgfhVk8Gtp6jOlX8wLRM9coR/ofGrVJxqY23lcD1OID1LerpHQ25HaWQAp7nUBj2PAAAA AAAA --------------ms060201050204070504040902-- From stpeter@stpeter.im Wed Dec 8 07:44:30 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BF303A694F; Wed, 8 Dec 2010 07:44:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.916 X-Spam-Level: X-Spam-Status: No, score=-101.916 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, J_CHICKENPOX_36=0.6, 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 qiv2iTkHVMRP; Wed, 8 Dec 2010 07:44:25 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id D041E3A6803; Wed, 8 Dec 2010 07:44:23 -0800 (PST) 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 2CE604009B; Wed, 8 Dec 2010 08:57:42 -0700 (MST) Message-ID: <4CFFA82C.80508@stpeter.im> Date: Wed, 08 Dec 2010 08:45:48 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: Ben Campbell References: <4CFEB1C5.4010103@stpeter.im> <4CFF114B.5010204@stpeter.im> <19F8341D-9815-4BB7-8837-83850FAC4F9E@nostrum.com> In-Reply-To: <19F8341D-9815-4BB7-8837-83850FAC4F9E@nostrum.com> X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms000104050702070508000801" Cc: draft-saintandre-tls-server-id-check.all@tools.ietf.org, General Area Review Team , certid@ietf.org Subject: Re: [certid] [Gen-art] Gen-ART LC Review of draft-saintandre-tls-server-id-check-11 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, 08 Dec 2010 15:44:30 -0000 This is a cryptographically signed message in MIME format. --------------ms000104050702070508000801 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable [further elided] On 12/7/10 10:44 PM, Ben Campbell wrote: >=20 > On Dec 7, 2010, at 11:02 PM, Peter Saint-Andre wrote: >=20 >> On 12/7/10 5:10 PM, Ben Campbell wrote: >>>=20 >>> On Dec 7, 2010, at 4:14 PM, Peter Saint-Andre wrote: >>>=20 >>> I note that (unless I missed it) the 5922 doesn't seem to allow >>> for falling back to a dNSName. Is that a reasonable choice for a >>> new protocol to make? >>=20 >> I think not. IMHO the fallback is a good idea. >=20 > But, from previous comments, such guidance does not belong in this > draft, right? I think that's right. >>> Given the previous conversation about how SIP seems to be the >>> only protocol with the equivalent scheme issue that actually uses >>> URI-IDs, and that it doesn't seem to need to worry about which >>> scheme its using at the moment, I no longer think this draft >>> needs to worry about it. If it were to say anything at all along >>> those lines, it would probably need to be along the lines of >>> KISS. For example, I don't think you want designers trying to >>> assert security properties by which scheme they include in a cert >>> (i.e. "foo" vs "foos") >>=20 >> Well, I do think a using protocol does need to specify which URI >> scheme names are acceptable for the application protocol. You >> wouldn't want a client to think that fubar://example.com identifies >> a SIP service. The tel: URI scheme is an interesting >> counter-example in some ways. >=20 > Not to mention "im:" and "pres:" :-) >=20 > Am I correct in assuming you mean that in the context of what schemes > they will put in a certificate, or match to a certificate, right?=20 Correct. I think this text is clearer in Section 3.1: 3. If the service using the certificate deploys a technology in which a server is programatically associated with a URI for security purposes (e.g., this is true of [SIP] as specified by [SIP-CERTS]), but not true of [HTTP] since [HTTP-TLS] does not describe usage of a URI-ID for HTTP services), then the certificate SHOULD include a URI-ID; the scheme SHALL be that of the protocol associated with the service type and the "authority" component SHALL be the fully-qualified DNS domain name of the service. A specification that re-uses this one MUST specify which URI schemes are to be considered acceptable in URI-IDs contained in PKIX certificates used for the application protocol (e.g., "sip" but not "sips" or "tel" for SIP as described in [SIP-SIPS], or perhaps http and https for HTTP as might be described in a future specification). > As > opposed to what schemes are legal in the application protocol as a > whole--since these are probably somewhat separate dimensions of > extensibility. (If the second, then I'm in over my depth in > meta-protocol design, and would certainly defer to an apps area > expert if one were handy ;-) ) Yeah, let's avoid that rat-hole. :) >>>>> -- 4.2.2: >>>>>=20 >>>>> Can we have a URI-ID example? >>>>=20 >>>> How's this? >>>>=20 >>>> A voice-over-IP (VoIP) user agent that is connecting via SIP >>>> to the voice service at "voice.example.edu" might have only >>>> one reference identifier: a URI-ID of "sip:voice.example.edu" >>>> (see [SIP-CERTS]). >>>>=20 >>>=20 >>> Would it make sense to say something to indicate this is true, >>> even though the connection may have been opened based on a URI >>> of "sip:user@voice.example.edu"? (I'm trying to figure out the >>> best way to word that without trying to invoke SIP request-URI vs >>> route set complexities, but my brain is tired. I will think >>> further about it.) >>=20 >> What do you mean by "the connection was opened based on a URI of=20 >> sip:user@voice.example.edu"? Yes, the client might know that it is=20 >> configured for an account with that URI, but in order to >> communicate with the application service it will need to resolve >> the DNS domain name (and application type) to an IP address. So >> that's the reference identifier. The presented identifier in the >> certificate will also be of the form sip:domain, not >> sip:user@domain. >>=20 >=20 > Sure, and I guess what I am talking about is how one derives a > reference identifier of sip:voice.example.edu from an address of > record (AoR) of sip:user@voice.example.edu. For example, I click on > the AoR on a web page, or I type it from Mr. User's business card. I > guess my point is it would be useful for the example to show that, > given the URI of a _resource_, you derive (extract?) a URI of a > _service_ to be the reference entry. You've mentioned that in text, > but it would be useful for the example to show it as well. Isn't that a matter for the application protocol? I want to authenticate with my IMAP server as user@mail.example.net, so my client needs to figure out which DNS domain name(s) it will attempt to resolve in order to communicate with the right IMAP server (perhaps the client checks its configuration or simply chops off the "user@" from the front). The result of that process is the source domain that's used as input to the verification procedures described in this I-D. It seems to me that the same goes for XMPP, SIP, etc. In Section 1.2 define source domain as: source domain: The fully-qualified DNS domain name that a client expects an application service to present in the certificate (e.g., "www.example.com"), typically input by a human user, configured into a client, or provided by reference such as in a hyperlink. The combination of a source domain and, optionally, a service type enables a client to construct one or more reference identifiers. In Section 2.1 we say: From the perspective of the application client or user, some names are direct because they are provided directly by a human user (e.g., via runtime input, prior configuration, or explicit acceptance of a client connection attempt) whereas other names are indirect because they are automatically resolved by the client based on user input (e.g., a target name resolved from a source name using DNS SRV records). This dimension matters most for certificate consumption, specifically verification as discussed in this document. In Section 4.2.1 we say: The inputs used by the client to construct its list of reference identifiers might be a URI that a user has typed into an interface (e.g., an HTTPS URL for a web site), configured account information (e.g., the domain name of a particular host or URI used for retrieving information or connecting to a network, which might be different from the server portion of the user's account name), a hyperlink in a web page that triggers a browser to retrieve a media object or script, or some other combination of information that can yield a source domain and a service type. The client might need to extract the source domain and service type from the input(s) it has received. The extracted data MUST include only information that can be securely parsed out of the inputs (e.g., extracting the fully-qualified DNS domain name from the "authority" component of a URI or extracting the service type from the scheme of a URI) or information for which the extraction is performed in a manner that is not subject to subversion by network attackers (e.g., pulling the data from a delegated domain that is explicitly established via client or system configuration, resolving the data via [DNSSEC], or obtaining the data from a third-party domain mapping service in which a human user has explicitly placed trust and with which the client communicates over a connection that provides both mutual authentication and integrity checking). These considerations apply only to extraction of the source domain from the inputs; naturally, if the inputs themselves are invalid or corrupt (e.g., a user has clicked a link provided by a malicious entity in a phishing attack), then the client might end up communicating with an unexpected application service. Do you feel we need to say more about how an application client determines the source domain? Is there something special about SIP AORs that this document does not cover (but should be covering)? Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms000104050702070508000801 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/ jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q 7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo 98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR 6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV 0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD 0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri 2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6 wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1 nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2 gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1 My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo 6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3 GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6 2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4 TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0 ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+ 39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c 6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2 0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0 H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0 dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTIw ODE1NDU0OFowIwYJKoZIhvcNAQkEMRYEFA3ym0IOmaVMboNwXPB59VSZ9994MF8GCSqGSIb3 DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG 9w0BAQEFAASCAQBZ8aVDnH469Bm83vthuPTDCQ1eB25LENYM+pun7DhOCVIn4+XP9GPvh8Gn YRoQKtFmH8MjlRwShehhITKRbqW70iH8Y7PIHD7gnJ9MNFqy1eznXSAB50Zcsv/99g9u+vWk wrvQBahOXrQQiT6EuGJbT1TF88gl/UlwXH56jnPkpb2YJZuUYp//yq+Zm7Hb2dlgBHO/S2YY EJwDanIP6KUwTkdPrW2ZrryyZk2DUyAqPCpoFzcC5uZ+kwVPhlEAgDIlJpgFbQWQBeuX2zoL 8knrsBRC4efJjqLOtTk7NN7zXe55CwVSfmej5fjdnoMxcYOFHU8XkY4Rw2GCttu3/I++AAAA AAAA --------------ms000104050702070508000801-- From Jeff.Hodges@KingsMountain.com Wed Dec 8 10:01:43 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBC823A696E for ; Wed, 8 Dec 2010 10:01:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.397 X-Spam-Level: X-Spam-Status: No, score=-101.397 tagged_above=-999 required=5 tests=[AWL=0.868, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 b2zBLFrDIiD5 for ; Wed, 8 Dec 2010 10:01:41 -0800 (PST) Received: from oproxy3-pub.bluehost.com (oproxy3-pub.bluehost.com [69.89.21.8]) by core3.amsl.com (Postfix) with SMTP id 167903A6961 for ; Wed, 8 Dec 2010 10:01:40 -0800 (PST) Received: (qmail 31176 invoked by uid 0); 8 Dec 2010 18:02:56 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy3.bluehost.com with SMTP; 8 Dec 2010 18:02:56 -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=3xfbKShdkwLp3zhDOubq/mmr8ZDyw/1nhdt4l8ieYlS1xiXNfeZEXZ9Cwgu9lccVX9L6CRk8BYEuGz4rvyMWHaKveHMOzDlsVELsRfMIsOCI4Wt2Loi9Exxt12Ln+SOX; 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 1PQOLv-00022C-MY for certid@ietf.org; Wed, 08 Dec 2010 11:02:55 -0700 Message-ID: <4CFFC84D.3060707@KingsMountain.com> Date: Wed, 08 Dec 2010 10:02:53 -0800 From: =JeffH User-Agent: Thunderbird 2.0.0.24 (X11/20101027) 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] fwd: Re: Second Last Call: draft-saintandre-tls-server-id-check (...) to BCP 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, 08 Dec 2010 18:01:43 -0000 Subject: Re: Second Last Call: draft-saintandre-tls-server-id-check (Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)) to BCP From: SM Date: Tue, 07 Dec 2010 13:36:43 -0800 To: ietf@ietf.org Cc: Peter Saint-Andre , Jeff Hodges At 04:36 18-11-10, 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 within Internet Public Key Infrastructure Using X.509 (PKIX) > Certificates in the Context of Transport Layer Security (TLS) ' > as a BCP > >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 In Section 2.2: 'A "traditional domain name", i.e., a fully-qualified domain name or "FQDN" (see [DNS-CONCEPTS]) all of whose labels are "LDH labels" as defined in [IDNA-DEFS].' It would be better to reference RFC 1123 for LDH labels instead of RFC 5890 unless the authors would like to adopt a terminology that is specific to IDNA. In Section 3.1: "Unless a profile of this specification allows continued support for the wildcard character '*', the fully-qualified DNS domain name portion of a presented identifier SHOULD NOT contain the wildcard character, whether as the complete left-most label within the identifier (following the definition of "label" from [DNS], e.g., "*.example.com") or as a fragment thereof (e.g., *oo.example.com, f*o.example.com, or foo*.example.com)." If the presented identifier is a fully-qualified DNS domain name (I assume that means FQDN), the left-most label cannot be a wildcard character according to LDH rules. I suggest rewriting that as: Unless a profile of this specification allows continued support for the wildcard character '*', the domain name portion of a presented identifier SHOULD NOT contain the wildcard character (e.g., "*.example.com") or as a fragment thereof (e.g., *oo.example.com, f*o.example.com, or foo*.example.com). In Section 4.2.1: "The client might need to extract the source domain and service type from the input(s) it has received. The extracted data MUST include only information that can be securely parsed out of the inputs (e.g., extracting the fully-qualified DNS domain name from the authority component of a URI or extracting the service type from the scheme of a URI) or information for which the extraction is performed in a manner that is not subject to subversion by network attackers (e.g., pulling the data from a delegated domain that is explicitly established via client or system configuration, resolving the data via [DNSSEC], or obtaining the data from a third-party domain mapping service in which a human user has explicitly placed trust and with which the client communicates over a connection that provides both mutual authentication and integrity checking)." I read part of the above as meaning that data can only be extracted from DNS if the data has been resolved via DNSSEC. Is that the intent? Section 4.3 discusses about how to seek a match against the list of reference identifiers. I found the thread at http://www.ietf.org/mail-archive/web/certid/current/msg00318.html informative. In Section 4.4.3: "A client employing this specification's rules MAY match the reference identifier against a presented identifier whose DNS domain name portion contains the wildcard character '*' as part or all of a label (following the definition of "label" from [DNS])" According to the definition of label in RFC 1035, the wildcard character cannot be part of a label. I suggest removing the last part of that sentence. FWIW, RFC 4592 updates the wildcard definition in RFC 1034 and uses the term "asterisk label". Was the comment about the security note ( http://www.ietf.org/mail-archive/web/certid/current/msg00427.html ) in Section 4.6.4 addressed? Regards, -sm _______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf From ben@nostrum.com Wed Dec 8 10:32: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 7AA6B3A6860; Wed, 8 Dec 2010 10:32:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.136 X-Spam-Level: X-Spam-Status: No, score=-102.136 tagged_above=-999 required=5 tests=[AWL=-0.136, BAYES_00=-2.599, J_CHICKENPOX_36=0.6, SPF_PASS=-0.001, 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 VyzJlvamg1Bz; Wed, 8 Dec 2010 10:32:48 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id B2B163A6826; Wed, 8 Dec 2010 10:32:47 -0800 (PST) Received: from dn3-174.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id oB8IYEMu062095 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 8 Dec 2010 12:34:14 -0600 (CST) (envelope-from ben@nostrum.com) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Ben Campbell In-Reply-To: <4CFFA82C.80508@stpeter.im> Date: Wed, 8 Dec 2010 12:34:13 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <210039F2-D368-485E-BECA-D3CE6D6B05D1@nostrum.com> References: <4CFEB1C5.4010103@stpeter.im> <4CFF114B.5010204@stpeter.im> <19F8341D-9815-4BB7-8837-83850FAC4F9E@nostrum.com> <4CFFA82C.80508@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1082) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: draft-saintandre-tls-server-id-check.all@tools.ietf.org, General Area Review Team , certid@ietf.org Subject: Re: [certid] [Gen-art] Gen-ART LC Review of draft-saintandre-tls-server-id-check-11 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, 08 Dec 2010 18:32:50 -0000 On Dec 8, 2010, at 9:45 AM, Peter Saint-Andre wrote: [...] >>>=20 >>> Well, I do think a using protocol does need to specify which URI >>> scheme names are acceptable for the application protocol. You >>> wouldn't want a client to think that fubar://example.com identifies >>> a SIP service. The tel: URI scheme is an interesting >>> counter-example in some ways. >>=20 >> Not to mention "im:" and "pres:" :-) >>=20 >> Am I correct in assuming you mean that in the context of what schemes >> they will put in a certificate, or match to a certificate, right?=20 >=20 > Correct. I think this text is clearer in Section 3.1: >=20 > 3. If the service using the certificate deploys a technology in > which a server is programatically associated with a URI for > security purposes (e.g., this is true of [SIP] as specified by > [SIP-CERTS]), but not true of [HTTP] since [HTTP-TLS] does not > describe usage of a URI-ID for HTTP services), then the > certificate SHOULD include a URI-ID; the scheme SHALL be that of > the protocol associated with the service type and the = "authority" > component SHALL be the fully-qualified DNS domain name of the > service. A specification that re-uses this one MUST specify > which URI schemes are to be considered acceptable in URI-IDs > contained in PKIX certificates used for the application protocol > (e.g., "sip" but not "sips" or "tel" for SIP as described in > [SIP-SIPS], or perhaps http and https for HTTP as might be > described in a future specification). >=20 WFM [...] >=20 >>>>>> -- 4.2.2: >>>>>>=20 >>>>>> Can we have a URI-ID example? >>>>>=20 >>>>> How's this? >>>>>=20 >>>>> A voice-over-IP (VoIP) user agent that is connecting via SIP >>>>> to the voice service at "voice.example.edu" might have only >>>>> one reference identifier: a URI-ID of "sip:voice.example.edu" >>>>> (see [SIP-CERTS]). >>>>>=20 >>>>=20 >>>> Would it make sense to say something to indicate this is true, >>>> even though the connection may have been opened based on a URI >>>> of "sip:user@voice.example.edu"? (I'm trying to figure out the >>>> best way to word that without trying to invoke SIP request-URI vs >>>> route set complexities, but my brain is tired. I will think >>>> further about it.) >>>=20 >>> What do you mean by "the connection was opened based on a URI of=20 >>> sip:user@voice.example.edu"? Yes, the client might know that it is=20= >>> configured for an account with that URI, but in order to >>> communicate with the application service it will need to resolve >>> the DNS domain name (and application type) to an IP address. So >>> that's the reference identifier. The presented identifier in the >>> certificate will also be of the form sip:domain, not >>> sip:user@domain. >>>=20 >>=20 >> Sure, and I guess what I am talking about is how one derives a >> reference identifier of sip:voice.example.edu from an address of >> record (AoR) of sip:user@voice.example.edu. For example, I click on >> the AoR on a web page, or I type it from Mr. User's business card. I >> guess my point is it would be useful for the example to show that, >> given the URI of a _resource_, you derive (extract?) a URI of a >> _service_ to be the reference entry. You've mentioned that in text, >> but it would be useful for the example to show it as well. >=20 > Isn't that a matter for the application protocol? >=20 > I want to authenticate with my IMAP server as user@mail.example.net, = so > my client needs to figure out which DNS domain name(s) it will attempt > to resolve in order to communicate with the right IMAP server (perhaps > the client checks its configuration or simply chops off the "user@" = from > the front). The result of that process is the source domain that's = used > as input to the verification procedures described in this I-D. It = seems > to me that the same goes for XMPP, SIP, etc. >=20 > In Section 1.2 define source domain as: >=20 > source domain: The fully-qualified DNS domain name that a client > expects an application service to present in the certificate > (e.g., "www.example.com"), typically input by a human user, > configured into a client, or provided by reference such as in a > hyperlink. The combination of a source domain and, optionally, a > service type enables a client to construct one or more reference > identifiers. >=20 > In Section 2.1 we say: >=20 > =46rom the perspective of the application client or user, some names > are direct because they are provided directly by a human user (e.g., > via runtime input, prior configuration, or explicit acceptance of a > client connection attempt) whereas other names are indirect because > they are automatically resolved by the client based on user input > (e.g., a target name resolved from a source name using DNS SRV > records). This dimension matters most for certificate consumption, > specifically verification as discussed in this document. >=20 > In Section 4.2.1 we say: >=20 > The inputs used by the client to construct its list of reference > identifiers might be a URI that a user has typed into an interface > (e.g., an HTTPS URL for a web site), configured account information > (e.g., the domain name of a particular host or URI used for > retrieving information or connecting to a network, which might be > different from the server portion of the user's account name), a > hyperlink in a web page that triggers a browser to retrieve a media > object or script, or some other combination of information that can > yield a source domain and a service type. >=20 > The client might need to extract the source domain and service type > from the input(s) it has received. The extracted data MUST include > only information that can be securely parsed out of the inputs = (e.g., > extracting the fully-qualified DNS domain name from the "authority" > component of a URI or extracting the service type from the scheme of > a URI) or information for which the extraction is performed in a > manner that is not subject to subversion by network attackers (e.g., > pulling the data from a delegated domain that is explicitly > established via client or system configuration, resolving the data > via [DNSSEC], or obtaining the data from a third-party domain = mapping > service in which a human user has explicitly placed trust and with > which the client communicates over a connection that provides both > mutual authentication and integrity checking). These considerations > apply only to extraction of the source domain from the inputs; > naturally, if the inputs themselves are invalid or corrupt (e.g., a > user has clicked a link provided by a malicious entity in a phishing > attack), then the client might end up communicating with an > unexpected application service. >=20 > Do you feel we need to say more about how an application client > determines the source domain? Is there something special about SIP = AORs > that this document does not cover (but should be covering)? >=20 As you mention, 4.2.1 says "The inputs used by the client to construct = its list of reference identifiers might be a URI that a user has typed = into an interface..." and "The client might need to extract the source = domain and service type from the input(s) it has received." In the case of SIP (and of HTTP if we pretended it used URI-IDs, that = input as typed in by a user is likely to contain stuff that has to be = stripped out of the reference identifier. For example, in SIP, this = input is very likely to be the AoR of the person you want to call. i.e. = a URI identifying a user. I am suggesting a soup to nuts example of how = a real world input such as that gets converted to a resulting URI = reference identity. I don't think this is peculiar to SIP, other than due to the fact that = SIP uses URI-IDs. If HTTP were to use URI-IDs, then you would have = similar issues of getting from the URI as entered by a user to a source = identifier in URI form. > Peter >=20 > --=20 > Peter Saint-Andre > https://stpeter.im/ >=20 >=20 >=20 From Jeff.Hodges@KingsMountain.com Wed Dec 8 11:13:10 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 B916E3A69A6 for ; Wed, 8 Dec 2010 11:13:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.701 X-Spam-Level: X-Spam-Status: No, score=-102.701 tagged_above=-999 required=5 tests=[AWL=1.564, BAYES_00=-2.599, GB_I_LETTER=-2, IP_NOT_FRIENDLY=0.334, 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 vDDmq-oc-Atx for ; Wed, 8 Dec 2010 11:13:09 -0800 (PST) Received: from cpoproxy1-pub.bluehost.com (cpoproxy1-pub.bluehost.com [69.89.21.11]) by core3.amsl.com (Postfix) with SMTP id 533743A69A2 for ; Wed, 8 Dec 2010 11:13:09 -0800 (PST) Received: (qmail 26703 invoked by uid 0); 8 Dec 2010 19:14:36 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by cpoproxy1.bluehost.com with SMTP; 8 Dec 2010 19:14: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=E7iINPOtvO4jfhKadzD0ckRfUoDNkVCbwYqcjwcokUPk0w8S2M7yKhiIvftC7hyM13Ct2jtvhmGh5bA2MTp4VUWv+QiYlifsIgOun0wa28ou1LwtJKZdH80eHb6wl1El; 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 1PQPTI-0005pm-4t; Wed, 08 Dec 2010 12:14:36 -0700 Message-ID: <4CFFD91A.2060808@KingsMountain.com> Date: Wed, 08 Dec 2010 11:14:34 -0800 From: =JeffH User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: SM , IETF Discussion List , draft-saintandre-tls-server-id-check.all@tools.ietf.org, 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] Second Last Call: draft-saintandre-tls-server-id-check (...) to BCP 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, 08 Dec 2010 19:13:10 -0000 [ adding certid@ list ] Thanks for the review SM. > In Section 2.2: > > 'A "traditional domain name", i.e., a fully-qualified domain name > or "FQDN" (see [DNS-CONCEPTS]) all of whose labels are "LDH > labels" as defined in [IDNA-DEFS].' > > It would be better to reference RFC 1123 for LDH labels instead of > RFC 5890 unless the authors would like to adopt a terminology that is > specific to IDNA. I looked into this in detail earlier this year -- it was discussed on ietf@ (during the initial IETF LC for this spec), and this particular issue resolution was summarized here (by John Klensin).. Re: Last Call: draft-saintandre-tls-server-id-check http://www.ietf.org/mail-archive/web/ietf/current/msg62601.html In brief summary, RFCs {1034,1035,1123,2181} do not define "letter-digit-hyphen" DNS name labels in a concisely referenceable fashion, nor particularly clearly. The IDNA specs have done the wider DNS-community a service by doing so, and at present the fashion in which "traditional domain name" is defined and cited is the best we can do. Given that IDNs are a deployed reality, every (new or updated) spec that discusses domain names going forward is going to need to reference the IDNA specs in some fashion, and probably should simply use the LDH-Label, A-Label, and U-Label nomenclature. (IMV) > In Section 3.1: > > "Unless a profile of this specification allows continued support > for the wildcard character '*', the fully-qualified DNS domain > name portion of a presented identifier SHOULD NOT contain the > wildcard character, whether as the complete left-most label > within the identifier (following the definition of "label" from > [DNS], e.g., "*.example.com") or as a fragment thereof (e.g., > *oo.example.com, f*o.example.com, or foo*.example.com)." > > If the presented identifier is a fully-qualified DNS domain name (I > assume that means FQDN), the left-most label cannot be a wildcard > character according to LDH rules. I suggest rewriting that as: > > Unless a profile of this specification allows continued support > for the wildcard character '*', the domain name portion of > a presented identifier SHOULD NOT contain the wildcard character > (e.g., "*.example.com") or as a fragment thereof (e.g., > *oo.example.com, f*o.example.com, or foo*.example.com). while I agree with your subtle substitution of.. "fully-qualified DNS domain name portion" ..with.. "domain name portion" ..however, I disagree with your further simplification of that paragraph because we feel we need to supply the more detailed context. > In Section 4.2.1: > > "The client might need to extract the source domain and service type > from the input(s) it has received. The extracted data MUST include > only information that can be securely parsed out of the inputs (e.g., > extracting the fully-qualified DNS domain name from the authority > component of a URI or extracting the service type from the scheme of > a URI) or information for which the extraction is performed in a > manner that is not subject to subversion by network attackers (e.g., > pulling the data from a delegated domain that is explicitly > established via client or system configuration, resolving the data > via [DNSSEC], or obtaining the data from a third-party domain mapping > service in which a human user has explicitly placed trust and with > which the client communicates over a connection that provides both > mutual authentication and integrity checking)." > > I read part of the above as meaning that data can only be extracted > from DNS if the data has been resolved via DNSSEC. Is that the intent? No, that is not the intent. We've further refined that paragraph as a result of a concurrent discussion with Ben Campbell (on certid@) and have this present working text.. The client might need to extract the source domain and service type from the input(s) it has received. The extracted data MUST include only information that can be securely parsed out of the inputs (e.g., extracting the fully-qualified DNS domain name from the "authority" component of a URI or extracting the service type from the scheme of a URI) or information for which the extraction is performed in a manner that is not subject to subversion by network attackers (e.g., pulling the data from a delegated domain that is explicitly established via client or system configuration, resolving the data via [DNSSEC], or obtaining the data from a third-party domain mapping service in which a human user has explicitly placed trust and with which the client communicates over a connection that provides both mutual authentication and integrity checking). These considerations apply only to extraction of the source domain from the inputs; naturally, if the inputs themselves are invalid or corrupt (e.g., a user has clicked a link provided by a malicious entity in a phishing attack), then the client might end up communicating with an unexpected application service. > Section 4.3 discusses about how to seek a match against the list of > reference identifiers. I found the thread at > http://www.ietf.org/mail-archive/web/certid/current/msg00318.html informative. > > In Section 4.4.3: > > "A client employing this specification's rules MAY match the reference > identifier against a presented identifier whose DNS domain name > portion contains the wildcard character '*' as part or all of a label > (following the definition of "label" from [DNS])" > > According to the definition of label in RFC 1035, the wildcard > character cannot be part of a label. I suggest removing the last > part of that sentence. You mean removing the parenthetical "(following the definition of "label" from [DNS])", yes? In reviewing RFC 1035 I see your concern, tho we'd like to reference a description of "label". I note that RFC 1034 [S3.1] seems to appropriately supply this, so I propose we keep the parenthetical but alter it to be.. (following the description of labels and domain names in [DNS-CONCEPTS]) > FWIW, RFC 4592 updates the wildcard > definition in RFC 1034 and uses the term "asterisk label". Yes, but that definition (and term) appears to be specific to underlying DNS internals, not to (pseudo) domain names as wielded (or "presented" (eg in certs)) in other protocols. > Was the comment about the security note ( > http://www.ietf.org/mail-archive/web/certid/current/msg00427.html ) > in Section 4.6.4 addressed? Yes, we believe so. thanks again for your review, =JeffH From stpeter@stpeter.im Wed Dec 8 11:43:21 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 7FAD83A6869; Wed, 8 Dec 2010 11:43:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.709 X-Spam-Level: X-Spam-Status: No, score=-101.709 tagged_above=-999 required=5 tests=[AWL=-0.310, BAYES_00=-2.599, J_CHICKENPOX_36=0.6, J_CHICKENPOX_72=0.6, 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 NgWswxiczpFQ; Wed, 8 Dec 2010 11:43:16 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id EE7923A6823; Wed, 8 Dec 2010 11:43:15 -0800 (PST) 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 AE43D4009B; Wed, 8 Dec 2010 12:56:34 -0700 (MST) Message-ID: <4CFFE028.5070102@stpeter.im> Date: Wed, 08 Dec 2010 12:44:40 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: Ben Campbell References: <4CFEB1C5.4010103@stpeter.im> <4CFF114B.5010204@stpeter.im> <19F8341D-9815-4BB7-8837-83850FAC4F9E@nostrum.com> <4CFFA82C.80508@stpeter.im> <210039F2-D368-485E-BECA-D3CE6D6B05D1@nostrum.com> In-Reply-To: <210039F2-D368-485E-BECA-D3CE6D6B05D1@nostrum.com> X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms020101060809080207070801" Cc: draft-saintandre-tls-server-id-check.all@tools.ietf.org, General Area Review Team , certid@ietf.org Subject: Re: [certid] [Gen-art] Gen-ART LC Review of draft-saintandre-tls-server-id-check-11 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, 08 Dec 2010 19:43:21 -0000 This is a cryptographically signed message in MIME format. --------------ms020101060809080207070801 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 12/8/10 11:34 AM, Ben Campbell wrote: >=20 > On Dec 8, 2010, at 9:45 AM, Peter Saint-Andre wrote: >=20 >>>>>>> -- 4.2.2: >>>>>>>=20 >>>>>>> Can we have a URI-ID example? >>>>>>=20 >>>>>> How's this? >>>>>>=20 >>>>>> A voice-over-IP (VoIP) user agent that is connecting via >>>>>> SIP to the voice service at "voice.example.edu" might have >>>>>> only one reference identifier: a URI-ID of >>>>>> "sip:voice.example.edu" (see [SIP-CERTS]). >>>>>=20 >>>>> Would it make sense to say something to indicate this is >>>>> true, even though the connection may have been opened based >>>>> on a URI of "sip:user@voice.example.edu"? (I'm trying to >>>>> figure out the best way to word that without trying to invoke >>>>> SIP request-URI vs route set complexities, but my brain is >>>>> tired. I will think further about it.) >>>>=20 >>>> What do you mean by "the connection was opened based on a URI >>>> of sip:user@voice.example.edu"? Yes, the client might know that >>>> it is configured for an account with that URI, but in order to=20 >>>> communicate with the application service it will need to >>>> resolve the DNS domain name (and application type) to an IP >>>> address. So that's the reference identifier. The presented >>>> identifier in the certificate will also be of the form >>>> sip:domain, not sip:user@domain. >>>=20 >>> Sure, and I guess what I am talking about is how one derives a=20 >>> reference identifier of sip:voice.example.edu from an address of=20 >>> record (AoR) of sip:user@voice.example.edu. For example, I click >>> on the AoR on a web page, or I type it from Mr. User's business >>> card. I guess my point is it would be useful for the example to >>> show that, given the URI of a _resource_, you derive (extract?) a >>> URI of a _service_ to be the reference entry. You've mentioned >>> that in text, but it would be useful for the example to show it >>> as well. >>=20 >> Isn't that a matter for the application protocol? >>=20 >> I want to authenticate with my IMAP server as >> user@mail.example.net, so my client needs to figure out which DNS >> domain name(s) it will attempt to resolve in order to communicate >> with the right IMAP server (perhaps the client checks its >> configuration or simply chops off the "user@" from the front). The >> result of that process is the source domain that's used as input to >> the verification procedures described in this I-D. It seems to me >> that the same goes for XMPP, SIP, etc. >>=20 >> In Section 1.2 define source domain as: >>=20 >> source domain: The fully-qualified DNS domain name that a client=20 >> expects an application service to present in the certificate (e.g., >> "www.example.com"), typically input by a human user, configured >> into a client, or provided by reference such as in a hyperlink. >> The combination of a source domain and, optionally, a service type >> enables a client to construct one or more reference identifiers. >>=20 >> In Section 2.1 we say: >>=20 >> From the perspective of the application client or user, some names=20 >> are direct because they are provided directly by a human user >> (e.g., via runtime input, prior configuration, or explicit >> acceptance of a client connection attempt) whereas other names are >> indirect because they are automatically resolved by the client >> based on user input (e.g., a target name resolved from a source >> name using DNS SRV records). This dimension matters most for >> certificate consumption, specifically verification as discussed in >> this document. >>=20 >> In Section 4.2.1 we say: >>=20 >> The inputs used by the client to construct its list of reference=20 >> identifiers might be a URI that a user has typed into an interface=20 >> (e.g., an HTTPS URL for a web site), configured account >> information (e.g., the domain name of a particular host or URI used >> for retrieving information or connecting to a network, which might >> be different from the server portion of the user's account name), >> a hyperlink in a web page that triggers a browser to retrieve a >> media object or script, or some other combination of information >> that can yield a source domain and a service type. >>=20 >> The client might need to extract the source domain and service >> type from the input(s) it has received. The extracted data MUST >> include only information that can be securely parsed out of the >> inputs (e.g., extracting the fully-qualified DNS domain name from >> the "authority" component of a URI or extracting the service type >> from the scheme of a URI) or information for which the extraction >> is performed in a manner that is not subject to subversion by >> network attackers (e.g., pulling the data from a delegated domain >> that is explicitly established via client or system configuration, >> resolving the data via [DNSSEC], or obtaining the data from a >> third-party domain mapping service in which a human user has >> explicitly placed trust and with which the client communicates over >> a connection that provides both mutual authentication and integrity >> checking). These considerations apply only to extraction of the >> source domain from the inputs; naturally, if the inputs themselves >> are invalid or corrupt (e.g., a user has clicked a link provided by >> a malicious entity in a phishing attack), then the client might end >> up communicating with an unexpected application service. >>=20 >> Do you feel we need to say more about how an application client=20 >> determines the source domain? Is there something special about SIP >> AORs that this document does not cover (but should be covering)? >=20 > As you mention, 4.2.1 says "The inputs used by the client to > construct its list of reference identifiers might be a URI that a > user has typed into an interface..." and "The client might need to > extract the source domain and service type from the input(s) it has > received." >=20 > In the case of SIP (and of HTTP if we pretended it used URI-IDs, that > input as typed in by a user is likely to contain stuff that has to be > stripped out of the reference identifier. For example, in SIP, this > input is very likely to be the AoR of the person you want to call. This is what I don't understand. Let's say you are sip:ben@nostrum.com and I am sip:stpeter@stpeter.im. Why does my client need to resolve nostrum.com in order to communicate with you? It seems to me that my client needs to resolve stpeter.im and then connect to that as my "home" server on the SIP network. My server then does the work of routing signalling traffic from stpeter.im to your server at nostrum.com, but my client doesn't communicate directly with nostrum.com because I'm not registered there. (I freely grant that my understanding might be based on email and XMPP, whereas SIP might have a different architecture.) > i.e. a URI identifying a user. I am suggesting a soup to nuts example > of how a real world input such as that gets converted to a resulting > URI reference identity. Yes, examples always help. > I don't think this is peculiar to SIP, other than due to the fact > that SIP uses URI-IDs. If HTTP were to use URI-IDs, then you would > have similar issues of getting from the URI as entered by a user to a > source identifier in URI form. In the case of HTTP, my client (browser) is going to pull out the "authority" component of the URI: http://www.example.com/foobar.html =3D> www.example.com But I think we already say that in Section 4.2.1: The client might need to extract the source domain and service type from the input(s) it has received. The extracted data MUST include only information that can be securely parsed out of the inputs (e.g., extracting the fully-qualified DNS domain name from the "authority" component of a URI or extracting the service type from the scheme of a URI) or information for which the extraction is performed in a manner that is not subject to subversion by network attackers (e.g., pulling the data from a delegated domain that is explicitly established via client or system configuration, resolving the data via [DNSSEC], or obtaining the data from a third-party domain mapping service in which a human user has explicitly placed trust and with which the client communicates over a connection that provides both mutual authentication and integrity checking). These considerations apply only to extraction of the source domain from the inputs; naturally, if the inputs themselves are invalid or corrupt (e.g., a user has clicked a link provided by a malicious entity in a phishing attack), then the client might end up communicating with an unexpected application service. See also Section 4.3: o For a reference identifier of type URI-ID, the DNS domain name portion is the "reg-name" part of the "authority" component and the application type portion is the scheme name matching the [ABNF] "scheme" rule from [URI] (not including the ':' separator). As previously mentioned, this document specifies that a URI-ID always contains an "authority" component whose "host" subcomponent contains a "reg-name". (Matching only the "reg-name" rule from [URI] limits verification to DNS domain names, thereby differentiating a URI-ID from a uniformResourceIdentifier entry that contains an IP address or a mere host name, or that does not contain an "authority" component at all.). Furthermore, note that extraction of the "reg-name" might necessitate normalization of the URI (as explained in [URI]. As an example, a URI-ID of "sip: voice.example.edu" would be split into a DNS domain name portion of "voice.example.edu" and an application type of "sip" (mapping to an application protocol of SIP as explained in [SIP-CERTS]). However, perhaps we need to say more in Section 4.2.1, including some examples? Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms020101060809080207070801 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/ jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q 7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo 98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR 6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV 0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD 0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri 2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6 wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1 nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2 gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1 My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo 6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3 GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6 2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4 TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0 ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+ 39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c 6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2 0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0 H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0 dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTIw ODE5NDQ0MFowIwYJKoZIhvcNAQkEMRYEFBZqFATA8VUBiDJH3k8PfTWVkSMgMF8GCSqGSIb3 DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG 9w0BAQEFAASCAQByECuc0RR/DUP8evd/bcp8743LwXTjjV3HvV4WXa5j2VQEpTKEJRZJ7dpz Kc0hCgkbslLDzCxVLGEdtAQ7wb8JdDtru+Q1epbvQlRpaZ9WnRNp7YhbwW1X/EIzPKPlZ/dM VSHi9NtNQoyxz0HD0kXzz1m5nbyZSl8cpqIujiO4/TFvTTbkQSLwT+E1787klbq+gRdKLiH8 2028b3A/jwEcsunAcAV1Vg3VmbTsu+q5hWuwOYIYwkRuJdrEkF0Wu7NPtZ+tY7G/dIMRZJY7 w2WiFkseX5fiDC3jBvgYP3WxFtAWi3CsC8BaL7Qi31s9QQIXdRuqovOnNfhEF9uSRvrLAAAA AAAA --------------ms020101060809080207070801-- From Jeff.Hodges@KingsMountain.com Wed Dec 8 11:50:44 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 9AE933A6988 for ; Wed, 8 Dec 2010 11:50:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.857 X-Spam-Level: X-Spam-Status: No, score=-101.857 tagged_above=-999 required=5 tests=[AWL=0.408, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 oe4AQDI1vWIV for ; Wed, 8 Dec 2010 11:50:43 -0800 (PST) Received: from oproxy3-pub.bluehost.com (oproxy3-pub.bluehost.com [69.89.21.8]) by core3.amsl.com (Postfix) with SMTP id 34E6B3A689A for ; Wed, 8 Dec 2010 11:50:43 -0800 (PST) Received: (qmail 19133 invoked by uid 0); 8 Dec 2010 19:50:59 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy3.bluehost.com with SMTP; 8 Dec 2010 19:50:59 -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:CC:Subject:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=r4ZbZsN5LCiYRJNC/GbhHX+vJZvL71Q48XMSmUzetdgUMZI52I3keEroTjoDRXnsPVZmNtJVfFZTp36/FnQi8Ekh3DRL1kcaSD8D49Sbq4ipaCiPgd3K5bmMfR2tpaLa; 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 1PQQ2U-00014t-U0; Wed, 08 Dec 2010 12:50:59 -0700 Message-ID: <4CFFE19F.1060603@KingsMountain.com> Date: Wed, 08 Dec 2010 11:50:55 -0800 From: =JeffH User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: Ben Campbell 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} Cc: draft-saintandre-tls-server-id-check.all@tools.ietf.org, General Area Review Team , certid@ietf.org Subject: Re: [certid] [Gen-art] Gen-ART LC Review of draft-saintandre-tls-server-id-check-11 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, 08 Dec 2010 19:50:44 -0000 > stpete sez.. >> In Section 4.2.1 we say: >> >> The inputs used by the client to construct its list of reference >> identifiers might be a URI that a user has typed into an interface >> (e.g., an HTTPS URL for a web site), configured account information >> (e.g., the domain name of a particular host or URI used for >> retrieving information or connecting to a network, which might be >> different from the server portion of the user's account name), a >> hyperlink in a web page that triggers a browser to retrieve a media >> object or script, or some other combination of information that can >> yield a source domain and a service type. >> >> The client might need to extract the source domain and service type >> from the input(s) it has received. The extracted data MUST include >> only information that can be securely parsed out of the inputs (e.g., >> extracting the fully-qualified DNS domain name from the "authority" >> component of a URI or extracting the service type from the scheme of ^^^^^^^^^^ I suggest we change this to "deriving". >> a URI) or information for which the extraction is performed in a >> manner that is not subject to subversion by network attackers (e.g., >> pulling the data from a delegated domain that is explicitly >> established via client or system configuration, resolving the data >> via [DNSSEC], or obtaining the data from a third-party domain mapping >> service in which a human user has explicitly placed trust and with >> which the client communicates over a connection that provides both >> mutual authentication and integrity checking). These considerations >> apply only to extraction of the source domain from the inputs; >> naturally, if the inputs themselves are invalid or corrupt (e.g., a >> user has clicked a link provided by a malicious entity in a phishing >> attack), then the client might end up communicating with an >> unexpected application service. >> >> Do you feel we need to say more about how an application client >> determines the source domain? Is there something special about SIP AORs >> that this document does not cover (but should be covering)? BenC replies.. > > I am suggesting a soup to nuts example of how a real world input such as > that gets converted to a resulting URI reference identity. So after the second para quoted above (from [S4.2.1]) how 'bout we add this.. For example, given an input URI of "sip:alice:pswd@example.net;transport=tcp?subject=project%20x&priority=urgent", the client derives the service type "sip" from the scheme, and the domain name "example.net" from the authority component. Also, given an input URI of "im:alice@example.net", the derived service type is "sip" (since the "im" scheme is defined as an abstract scheme in the SIP context by [SIP-IM] (RFC 3428)), and the domain name is again "example.net". ? =JeffH From stpeter@stpeter.im Wed Dec 8 12:14: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 8BDBE3A6886; Wed, 8 Dec 2010 12:14:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.257 X-Spam-Level: X-Spam-Status: No, score=-102.257 tagged_above=-999 required=5 tests=[AWL=0.342, BAYES_00=-2.599, 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 WPk6YHE7fT-c; Wed, 8 Dec 2010 12:14:40 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 3029A3A6870; Wed, 8 Dec 2010 12:14:40 -0800 (PST) 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 B85374009B; Wed, 8 Dec 2010 13:27:59 -0700 (MST) Message-ID: <4CFFE784.20302@stpeter.im> Date: Wed, 08 Dec 2010 13:16:04 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: =JeffH References: <4CFFE19F.1060603@KingsMountain.com> In-Reply-To: <4CFFE19F.1060603@KingsMountain.com> X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms010302080307000801050200" Cc: Ben Campbell , General Area Review Team , certid@ietf.org, draft-saintandre-tls-server-id-check.all@tools.ietf.org Subject: Re: [certid] [Gen-art] Gen-ART LC Review of draft-saintandre-tls-server-id-check-11 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, 08 Dec 2010 20:14:41 -0000 This is a cryptographically signed message in MIME format. --------------ms010302080307000801050200 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 12/8/10 12:50 PM, =3DJeffH wrote: > >=20 >> stpete sez.. >>> In Section 4.2.1 we say: >>> >>> The inputs used by the client to construct its list of reference >>> identifiers might be a URI that a user has typed into an interface >>> (e.g., an HTTPS URL for a web site), configured account information= >>> (e.g., the domain name of a particular host or URI used for >>> retrieving information or connecting to a network, which might be >>> different from the server portion of the user's account name), a >>> hyperlink in a web page that triggers a browser to retrieve a media= >>> object or script, or some other combination of information that can= >>> yield a source domain and a service type. >>> >>> The client might need to extract the source domain and service type= >>> from the input(s) it has received. The extracted data MUST include= >>> only information that can be securely parsed out of the inputs (e.g= =2E, >>> extracting the fully-qualified DNS domain name from the "authority"= >>> component of a URI or extracting the service type from the scheme o= f > ^^^^^^^^^^ >=20 > I suggest we change this to "deriving". After an IM chat with Jeff, I agree. >>> a URI) or information for which the extraction is performed in a >>> manner that is not subject to subversion by network attackers (e.g.= , >>> pulling the data from a delegated domain that is explicitly >>> established via client or system configuration, resolving the data >>> via [DNSSEC], or obtaining the data from a third-party domain mappi= ng >>> service in which a human user has explicitly placed trust and with >>> which the client communicates over a connection that provides both >>> mutual authentication and integrity checking). These consideration= s >>> apply only to extraction of the source domain from the inputs; >>> naturally, if the inputs themselves are invalid or corrupt (e.g., a= >>> user has clicked a link provided by a malicious entity in a phishin= g >>> attack), then the client might end up communicating with an >>> unexpected application service. >>> >>> Do you feel we need to say more about how an application client >>> determines the source domain? Is there something special about SIP AO= Rs >>> that this document does not cover (but should be covering)? >=20 >=20 > BenC replies.. >> > >> I am suggesting a soup to nuts example of how a real world input such = as >> that gets converted to a resulting URI reference identity. >=20 >=20 > So after the second para quoted above (from [S4.2.1]) how 'bout we add > this.. >=20 >=20 > For example, given an input URI of > "sip:alice:pswd@example.net;transport=3Dtcp?subject=3Dproject%20x&prior= ity=3Durgent", > the client derives the service type "sip" from the scheme, and the > domain name "example.net" from the authority component.=20 Looks good. I love gnarly URIs. :) > Also, given an > input URI of "im:alice@example.net", the derived service type is "sip" > (since the "im" scheme is defined as an abstract scheme in the SIP > context by [SIP-IM] (RFC 3428)), and the domain name is again > "example.net". Well, the im: and pres: URIs can result in a derived service type of "xmpp", too. It depends on what a service has deployed... http://tools.ietf.org/html/rfc3860 http://www.iana.org/assignments/im-srv-labels/im-srv-labels.xhtml Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms010302080307000801050200 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/ jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q 7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo 98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR 6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV 0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD 0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri 2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6 wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1 nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2 gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1 My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo 6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3 GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6 2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4 TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0 ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+ 39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c 6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2 0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0 H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0 dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTIw ODIwMTYwNFowIwYJKoZIhvcNAQkEMRYEFG/pGxcBD9etHl4f9WPsgSKQVqv1MF8GCSqGSIb3 DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG 9w0BAQEFAASCAQAl/8pUTrXpLkBsUk8+dAVZhQqtkFAo0jkdTIjw6HK9lB7Mn0FfSaPtYQzh jD6nvKlks2MO8JSi4CIhLendrbDZtuz/W3o3PXaD9ajgaNaeyGLRML1sNZktxZYZ0ii7yg33 5mDkMq2ltl12NIStEFuQfoBxDJsPCwsMIcgqemD97GGzYnDB8zNcNQFBG/jRwCwXlsVc4JMm QshS5RPfCxPSrmfiqDU9UPJGALU0TprgvYut1y9MmdbH5o+bEuZDQXj7FrQtIhJdEhYVZEcm XOgvhqZe7ewct4LmtIW6iLQk6YYWhdfzHwfdZDTCqVmoeEovLB2zh5MxBw8jHSLX6GceAAAA AAAA --------------ms010302080307000801050200-- From stpeter@stpeter.im Wed Dec 8 12:22:04 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B4263A696A; Wed, 8 Dec 2010 12:22:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.306 X-Spam-Level: X-Spam-Status: No, score=-102.306 tagged_above=-999 required=5 tests=[AWL=0.293, BAYES_00=-2.599, 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 c1ORsDPw+Zv4; Wed, 8 Dec 2010 12:22:03 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id EA9CE3A6886; Wed, 8 Dec 2010 12:22:02 -0800 (PST) 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 D6EF14009B; Wed, 8 Dec 2010 13:35:17 -0700 (MST) Message-ID: <4CFFE93B.1050802@stpeter.im> Date: Wed, 08 Dec 2010 13:23:23 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: =JeffH References: <4CFFE19F.1060603@KingsMountain.com> <4CFFE784.20302@stpeter.im> In-Reply-To: <4CFFE784.20302@stpeter.im> X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms040707030708080701020300" Cc: Ben Campbell , General Area Review Team , certid@ietf.org, draft-saintandre-tls-server-id-check.all@tools.ietf.org Subject: Re: [certid] [Gen-art] Gen-ART LC Review of draft-saintandre-tls-server-id-check-11 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, 08 Dec 2010 20:22:04 -0000 This is a cryptographically signed message in MIME format. --------------ms040707030708080701020300 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 12/8/10 1:16 PM, Peter Saint-Andre wrote: > On 12/8/10 12:50 PM, =3DJeffH wrote: > >> Also, given an >> input URI of "im:alice@example.net", the derived service type is "sip"= >> (since the "im" scheme is defined as an abstract scheme in the SIP >> context by [SIP-IM] (RFC 3428)), and the domain name is again >> "example.net". >=20 > Well, the im: and pres: URIs can result in a derived service type of > "xmpp", too. It depends on what a service has deployed... >=20 > http://tools.ietf.org/html/rfc3860 >=20 > http://www.iana.org/assignments/im-srv-labels/im-srv-labels.xhtml We can tweak it to: As an example, given an input URI of "sip:alice:pswd@ example.net;transport=3Dtcp?subject=3Dproject%20x&priority=3Durgent", = the client derives the service type "sip" from the scheme and the domain name "example.net" from the authority component. Also, given an input URI of "im:alice@example.net", the derived service type might be "sip", depending on how the example.net service is deployed (since the "im" scheme [CPIM] is defined as an abstract scheme in the SIP context by [SIP-IM]), and the domain name would again be "example.net". /psa --------------ms040707030708080701020300 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/ jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q 7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo 98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR 6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV 0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD 0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri 2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6 wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1 nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2 gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1 My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo 6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3 GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6 2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4 TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0 ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+ 39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c 6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2 0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0 H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0 dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTIw ODIwMjMyM1owIwYJKoZIhvcNAQkEMRYEFPlFFPfQTwSmVNgbKutQy6fxurx0MF8GCSqGSIb3 DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG 9w0BAQEFAASCAQAi+w3g7qaE8x0ietZjsLtG2Mn0h8yAfMBzQ1FQEB0czwSz7jYjhhAyGiwu Vgcx7Ns6DF/0j83Vey8nc6SO1mGlh9Zwbw1PDviXgswIcPqxYBdkskR4MtDbWlUov903E0jq slgWP9txn6u+q0W8vYsF6FENhhvS+/zmeglvUN/ohtUJomqEMOkkFHx7eXEwjxvnhSK/PHdo NRO4Wu8fdIGJKepWY4KgFhMQL0jVbJi3+KHrUxUabYpGxvj4PQh/JhP4z7NK8qo5GpvNLfod xtVXS54kbbI1oZ0+TZhACje5c95KgjxQBbr7KNTxBguNBmpeG+Z7ABOT40HdgqMsW1svAAAA AAAA --------------ms040707030708080701020300-- From Jeff.Hodges@KingsMountain.com Wed Dec 8 12:44:07 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 1EBA63A6890 for ; Wed, 8 Dec 2010 12:44:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.092 X-Spam-Level: X-Spam-Status: No, score=-102.092 tagged_above=-999 required=5 tests=[AWL=0.507, BAYES_00=-2.599, 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 x84mM0kFhd+G for ; Wed, 8 Dec 2010 12:44:06 -0800 (PST) Received: from oproxy1-pub.bluehost.com (oproxy1-pub.bluehost.com [66.147.249.253]) by core3.amsl.com (Postfix) with SMTP id F337F3A687D for ; Wed, 8 Dec 2010 12:44:05 -0800 (PST) Received: (qmail 13218 invoked by uid 0); 8 Dec 2010 20:45:33 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy1.bluehost.com.bluehost.com with SMTP; 8 Dec 2010 20:45:33 -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=uqmfS4ao8cs9C2qoU2va2sekzS2DMOVngBpB+X2Xy/NL4y09Pnap6uom+NfjGxnrfcMCK24AMAYt4MLZjAs3j+2ur4CO6BbTVgCbmU6gOiIgScM78BGl548bdLZgvGOF; 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 1PQQtJ-00064o-JK; Wed, 08 Dec 2010 13:45:33 -0700 Message-ID: <4CFFEE6B.4060306@KingsMountain.com> Date: Wed, 08 Dec 2010 12:45:31 -0800 From: =JeffH User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: Peter Saint-Andre , General Area Review Team , certid@ietf.org, draft-saintandre-tls-server-id-check.all@tools.ietf.org 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] [Gen-art] Gen-ART LC Review of draft-saintandre-tls-server-id-check-11 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, 08 Dec 2010 20:44:07 -0000 > We can tweak it to: > > As an example, given an input URI of "sip:alice:pswd@ > example.net;transport=tcp?subject=project%20x&priority=urgent", the > client derives the service type "sip" from the scheme and the domain > name "example.net" from the authority component. Also, given an > input URI of "im:alice@example.net", the derived service type might > be "sip", depending on how the example.net service is deployed (since > the "im" scheme [CPIM] is defined as an abstract scheme in the SIP > context by [SIP-IM]), and the domain name would again be > "example.net". works for me. someone just noted offlist that we should perhaps change the scheme of the first URI to "sips". =JeffH From Jeff.Hodges@KingsMountain.com Wed Dec 8 12:47: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 A5A4F3A6890 for ; Wed, 8 Dec 2010 12:47:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.016 X-Spam-Level: X-Spam-Status: No, score=-102.016 tagged_above=-999 required=5 tests=[AWL=0.249, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 3B-HEAS-0U2l for ; Wed, 8 Dec 2010 12:47:27 -0800 (PST) Received: from oproxy3-pub.bluehost.com (oproxy3-pub.bluehost.com [69.89.21.8]) by core3.amsl.com (Postfix) with SMTP id ABE653A6860 for ; Wed, 8 Dec 2010 12:47:27 -0800 (PST) Received: (qmail 24289 invoked by uid 0); 8 Dec 2010 20:48:55 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy3.bluehost.com with SMTP; 8 Dec 2010 20:48:55 -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=K1Uze0JwNyC5WQNKzH1TneNWCa3bRecIM4oUoW+o6hLC0NObRzd06UkSz+NUsRKgQ+M/rHeSW95KpLLioXP3m2s2/nkAKndnkR+ORA1xhrddSW2FPzzymUOskJo9kIzf; 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 1PQQwZ-0001Jj-FM; Wed, 08 Dec 2010 13:48:55 -0700 Message-ID: <4CFFEF35.3090200@KingsMountain.com> Date: Wed, 08 Dec 2010 12:48:53 -0800 From: =JeffH User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: IETF cert-based identity , General Area Review Team , Peter Saint-Andre , Ben Campbell 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] applicability of draft-saintandre-tls-server-id-check (was: Gen-ART LC Review...) 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, 08 Dec 2010 20:47:28 -0000 > In general, I think this document is describing the tools available to > protocol designers, not telling protocol designers which tools to use. Well, the original intent of this spec was to (simply, heh) specify how to match one's reference ID to the presented ID (tho we hadn't yet invented those terms) returned in the end-entity cert during TLS handshake, so protocol designers/specifiers didn't have to re-invent it (and do so differently) for each spec going forward. So I'd characterize it as listing (and defining degrees-of-freedom of) the tools available (eg DNS-ID, SRV-ID, URI-ID, etc.), and then defining how to perform matching given the tool. =JeffH From stpeter@stpeter.im Wed Dec 8 12:55:49 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 56C193A6995; Wed, 8 Dec 2010 12:55:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.343 X-Spam-Level: X-Spam-Status: No, score=-102.343 tagged_above=-999 required=5 tests=[AWL=0.256, BAYES_00=-2.599, 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 4G5vBuTvzoAD; Wed, 8 Dec 2010 12:55:48 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 8AB8E3A6988; Wed, 8 Dec 2010 12:55:48 -0800 (PST) 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 5427B4009B; Wed, 8 Dec 2010 14:09:08 -0700 (MST) Message-ID: <4CFFF129.10204@stpeter.im> Date: Wed, 08 Dec 2010 13:57:13 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: =JeffH References: <4CFFEE6B.4060306@KingsMountain.com> In-Reply-To: <4CFFEE6B.4060306@KingsMountain.com> X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms080505050002030703070203" Cc: draft-saintandre-tls-server-id-check.all@tools.ietf.org, General Area Review Team , certid@ietf.org Subject: Re: [certid] [Gen-art] Gen-ART LC Review of draft-saintandre-tls-server-id-check-11 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, 08 Dec 2010 20:55:49 -0000 This is a cryptographically signed message in MIME format. --------------ms080505050002030703070203 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 12/8/10 1:45 PM, =3DJeffH wrote: >> We can tweak it to: >> >> As an example, given an input URI of "sip:alice:pswd@ >> example.net;transport=3Dtcp?subject=3Dproject%20x&priority=3Durgent= ", the >> client derives the service type "sip" from the scheme and the domai= n >> name "example.net" from the authority component. Also, given an >> input URI of "im:alice@example.net", the derived service type might= >> be "sip", depending on how the example.net service is deployed (sin= ce >> the "im" scheme [CPIM] is defined as an abstract scheme in the SIP >> context by [SIP-IM]), and the domain name would again be >> "example.net". >=20 > works for me. >=20 > someone just noted offlist that we should perhaps change the scheme of > the first URI to "sips". Done. Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms080505050002030703070203 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/ jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q 7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo 98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR 6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV 0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD 0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri 2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6 wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1 nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2 gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1 My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo 6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3 GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6 2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4 TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0 ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+ 39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c 6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2 0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0 H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0 dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTIw ODIwNTcxM1owIwYJKoZIhvcNAQkEMRYEFLKLbE0XNVXryR/JlVZNynohZSxfMF8GCSqGSIb3 DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG 9w0BAQEFAASCAQC1rEGqgC0JF5952Uh7CEiXnSz/B5JUcnR0lSriERANjxajC0EBsF7kzCFh 1WRvRcPqBKNlBFcpC97AqnRXbTsT6COBzP0hLNiuSIkShG1I/F/3v7176A/ThCdwAkiEo3pk G6fVmwY0ULY8ilOO+ebNoA0m6WNMOjfhGDfdEJRYN+l0xh8kFayQ6hUCiouN10iFYH0IamRu bDXdY/DzBBnCKN52aCyWUXLVoV1nWz/HK5YrkersVkUVj/ebYZT8eV0CoQSdFHtgjWJWpqsT zkKJRPqojEHG9hZiHfdTyXC9TO9FQmUcfx/rUUX7zQRGvMTFgy8AVv9uh48jQThpTb9JAAAA AAAA --------------ms080505050002030703070203-- From stpeter@stpeter.im Wed Dec 8 13: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 779AC3A688D; Wed, 8 Dec 2010 13:02:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.371 X-Spam-Level: X-Spam-Status: No, score=-102.371 tagged_above=-999 required=5 tests=[AWL=0.228, BAYES_00=-2.599, 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 p7REn0aUG+nN; Wed, 8 Dec 2010 13:02:00 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 8FD603A686A; Wed, 8 Dec 2010 13:02:00 -0800 (PST) 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 B5F0C4009B; Wed, 8 Dec 2010 14:15:20 -0700 (MST) Message-ID: <4CFFF29E.6040804@stpeter.im> Date: Wed, 08 Dec 2010 14:03:26 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: =JeffH References: <4CFFEF35.3090200@KingsMountain.com> In-Reply-To: <4CFFEF35.3090200@KingsMountain.com> X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms050206070201010106000001" Cc: Ben Campbell , General Area Review Team , IETF cert-based identity Subject: Re: [certid] applicability of draft-saintandre-tls-server-id-check (was: Gen-ART LC Review...) 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, 08 Dec 2010 21:02:01 -0000 This is a cryptographically signed message in MIME format. --------------ms050206070201010106000001 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 12/8/10 1:48 PM, =3DJeffH wrote: >> In general, I think this document is describing the tools available to= >> protocol designers, not telling protocol designers which tools to use.= >=20 > Well, the original intent of this spec was to (simply, heh) specify how= > to match one's reference ID to the presented ID (tho we hadn't yet > invented those terms) returned in the end-entity cert during TLS > handshake, so protocol designers/specifiers didn't have to re-invent it= > (and do so differently) for each spec going forward. >=20 > So I'd characterize it as listing (and defining degrees-of-freedom of) > the tools available (eg DNS-ID, SRV-ID, URI-ID, etc.), and then definin= g > how to perform matching given the tool. Yes, that is more accurate. As we discussed via IM, originally we thought it would be simple to lay down the law for all application protocols, but our prescriptions have become a bit more relaxed as we've realized how tangled the landscape is... Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms050206070201010106000001 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/ jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q 7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo 98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR 6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV 0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD 0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri 2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6 wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1 nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2 gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1 My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo 6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3 GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6 2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4 TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0 ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+ 39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c 6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2 0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0 H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0 dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTIw ODIxMDMyNlowIwYJKoZIhvcNAQkEMRYEFIW3iH8HE0pnX9IU4oAh2M0hWG8LMF8GCSqGSIb3 DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG 9w0BAQEFAASCAQCFtC//vYB4I1cbM1E4GiJ4QVGR7M4WL0itivi/IBnyPGCwo2Z+rvteIcaz nApBqdLITQkAnMc2UAaEx3l6p/70t/BubraighI1NU3ztdbAjHIGK2rz/5llp8NXd/AMTBRo M49BDIppaB17pCMuTYPi7KFhMHe8evvqCa14fTYVNqntRPHmuYxRyJdbxm0+5cqR02FTQRX8 dLwISm1EYxFxTDMC2KBJQGQEF3zDJPlez1icv2KHaPj3nBwcpt91G1hradAACivttV3igTot ptOpkhRorrSnSJk4TanGCRh9fUmpRfV2rv87mEBISLmg1sm2lNhwRYjpHoddbdV+yTeBAAAA AAAA --------------ms050206070201010106000001-- From Jeff.Hodges@KingsMountain.com Wed Dec 8 13:03:00 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 862263A697D for ; Wed, 8 Dec 2010 13:03:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.222 X-Spam-Level: X-Spam-Status: No, score=-102.222 tagged_above=-999 required=5 tests=[AWL=0.377, BAYES_00=-2.599, 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 EGtE6uVOe4uM for ; Wed, 8 Dec 2010 13:02:59 -0800 (PST) Received: from oproxy1-pub.bluehost.com (oproxy1-pub.bluehost.com [66.147.249.253]) by core3.amsl.com (Postfix) with SMTP id 27C8B3A686A for ; Wed, 8 Dec 2010 13:02:59 -0800 (PST) Received: (qmail 22622 invoked by uid 0); 8 Dec 2010 21:04:27 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy1.bluehost.com.bluehost.com with SMTP; 8 Dec 2010 21:04:27 -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:CC:Subject:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=NyP9SDtynWklwWFqSgw4aktNflIT1Wwcu690afnMboFUh70PIz4/h3x6pWUdDhDnqJN6cp3daK60hm3yeh8ueatjFX76B2+c2Wi4VJ0aUtj4jpDG8mKfL4Ayxaf/28lh; 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 1PQRBa-00027A-LE; Wed, 08 Dec 2010 14:04:26 -0700 Message-ID: <4CFFF2D8.4070408@KingsMountain.com> Date: Wed, 08 Dec 2010 13:04:24 -0800 From: =JeffH User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: Paul Hoffman 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} Cc: Ben Campbell , General Area Review Team , IETF cert-based identity , =JeffH , draft-saintandre-tls-server-id-check.all@tools.ietf.org Subject: Re: [certid] Gen-ART LC Review of draft-saintandre-tls-server-id-check-11 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, 08 Dec 2010 21:03:00 -0000 stpete replied.. > > On 12/7/10 8:01 AM, Paul Hoffman wrote: >> [[ Much abbreviated ]] >> >> At 9:10 PM -0700 12/6/10, Peter Saint-Andre wrote: >>>>>> -- 3.1, rule 6: >>>>>> >>>>>> Can you motivate why this is not a MUST NOT? >>>> The reason for allowing this wiggle-room is that (for better or worse).. >>>> >>>> 1. the CA/Browser Forum Extended Validation (EV) Certificate Guidelines >>>> explicitly allow for multiple CN-IDs >>>> >>>> 2. It's a not-totally-uncommon current practice to have certs that do >>>> have >>>> mutiple CN-IDs, eg from Comodo (whether EV or DV (domain valivdated)). >>>> >>>> 3. Virtual hosting multiple distinct-domain TLS servers on one entity is >>>> difficult today if one desires wide desktop client support because >>>> a certain vendor's older-but-still-widely-deployed-OS does not (yet?) >>>> support the TLS Server Name Indication extension. Thus having one >>>> cert with all the domains jammed in it (as either/both CN-IDs or/and >>>> DNS-IDs) is a workaround (eg Content Delivery Networks use this). >>>> >>>> >>>> So some argue that if we MUST NOT multiple CN-IDs at this point, it is >>>> flying in the face of present reality and might contribute to acquiring >>>> an attained reputation for this BCP that is lower than we desire. >>>> >>>> There is also concern on the part of CA folk about client-side TLS libs >>>> and their support for name matching (ie some (old?) one(s) will only >>>> match on CN-ID). >>>> >>>> For a CA perspective on all the above, see... >>>> >>>> Re: [certid] weird CN-IDs (subjectCommonName) in SSL Labs Survey Data >>>> http://www.ietf.org/mail-archive/web/certid/current/msg00502.html >>> >>> +1 to all that. >> >> Putting an explanation such as the above in the document will help future >> IETFs to decide when to make this a MUST NOT. It might also help the CA/Browser >> Forum and specific CAs see that they should stop doing this ASAP, and maybe >> even convince a particular legacy OS vendor to support TLS SNI. > > Sigh. I don't particularly want to add a long informational note that > qualifies eight words in the spec, but you're right. :) agreed. =JeffH From ben@nostrum.com Wed Dec 8 13:29: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 3392D3A698E; Wed, 8 Dec 2010 13:29:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.819 X-Spam-Level: X-Spam-Status: No, score=-101.819 tagged_above=-999 required=5 tests=[AWL=-0.419, BAYES_00=-2.599, J_CHICKENPOX_62=0.6, J_CHICKENPOX_72=0.6, SPF_PASS=-0.001, 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 e+dUQTR6Z40b; Wed, 8 Dec 2010 13:29:26 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 0E8E33A6818; Wed, 8 Dec 2010 13:29:25 -0800 (PST) Received: from dn3-174.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id oB8LUqEO076048 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 8 Dec 2010 15:30:52 -0600 (CST) (envelope-from ben@nostrum.com) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Ben Campbell In-Reply-To: <4CFFE028.5070102@stpeter.im> Date: Wed, 8 Dec 2010 15:30:52 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <1880840A-D7F4-4E93-A6F9-DD097260AE52@nostrum.com> References: <4CFEB1C5.4010103@stpeter.im> <4CFF114B.5010204@stpeter.im> <19F8341D-9815-4BB7-8837-83850FAC4F9E@nostrum.com> <4CFFA82C.80508@stpeter.im> <210039F2-D368-485E-BECA-D3CE6D6B05D1@nostrum.com> <4CFFE028.5070102@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1082) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: draft-saintandre-tls-server-id-check.all@tools.ietf.org, General Area Review Team , certid@ietf.org Subject: Re: [certid] [Gen-art] Gen-ART LC Review of draft-saintandre-tls-server-id-check-11 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, 08 Dec 2010 21:29:28 -0000 On Dec 8, 2010, at 1:44 PM, Peter Saint-Andre wrote: > On 12/8/10 11:34 AM, Ben Campbell wrote: [...] >>=20 >> As you mention, 4.2.1 says "The inputs used by the client to >> construct its list of reference identifiers might be a URI that a >> user has typed into an interface..." and "The client might need to >> extract the source domain and service type from the input(s) it has >> received." >>=20 >> In the case of SIP (and of HTTP if we pretended it used URI-IDs, that >> input as typed in by a user is likely to contain stuff that has to be >> stripped out of the reference identifier. For example, in SIP, this >> input is very likely to be the AoR of the person you want to call. >=20 > This is what I don't understand. >=20 > Let's say you are sip:ben@nostrum.com and I am sip:stpeter@stpeter.im. > Why does my client need to resolve nostrum.com in order to communicate > with you? It seems to me that my client needs to resolve stpeter.im = and > then connect to that as my "home" server on the SIP network. My server > then does the work of routing signalling traffic from stpeter.im to = your > server at nostrum.com, but my client doesn't communicate directly with > nostrum.com because I'm not registered there. >=20 It could work either way. It's common for me to have a service that I = send outbound requests through, but it's not required by the protocol or = the architecture so much as it is an artifact of pesky NATs and SBCs. = But even if you do connect via your own service, some device in the = "stpeter.im" service is going to eventually have to connect to the = "nostrum.com" service. It does that based on the original user input of = "sip:ben@nostrum.com". > (I freely grant that my understanding might be based on email and = XMPP, > whereas SIP might have a different architecture.) Even for XMPP and email, something in your service would eventually have = to connect to something in my service, based on my JID or email address.=20= HTTP might be a better example. If I enter = "https://stpeter.im/index.php/2010/11/17/another-xmpp-wg-update/" into = my browser, it by default attempts to form a TLS connection directly to = speter.im. (Too bad HTTP doesn't use URI-IDs, since it would make an = easier to understand example than SIP.) >=20 >> i.e. a URI identifying a user. I am suggesting a soup to nuts example >> of how a real world input such as that gets converted to a resulting >> URI reference identity. >=20 > Yes, examples always help. >=20 >> I don't think this is peculiar to SIP, other than due to the fact >> that SIP uses URI-IDs. If HTTP were to use URI-IDs, then you would >> have similar issues of getting from the URI as entered by a user to a >> source identifier in URI form. >=20 > In the case of HTTP, my client (browser) is going to pull out the > "authority" component of the URI: >=20 > http://www.example.com/foobar.html =3D> www.example.com >=20 > But I think we already say that in Section 4.2.1: >=20 > The client might need to extract the source domain and service type > from the input(s) it has received. The extracted data MUST include > only information that can be securely parsed out of the inputs = (e.g., > extracting the fully-qualified DNS domain name from the "authority" > component of a URI or extracting the service type from the scheme of > a URI) or information for which the extraction is performed in a > manner that is not subject to subversion by network attackers (e.g., > pulling the data from a delegated domain that is explicitly > established via client or system configuration, resolving the data > via [DNSSEC], or obtaining the data from a third-party domain = mapping > service in which a human user has explicitly placed trust and with > which the client communicates over a connection that provides both > mutual authentication and integrity checking). These considerations > apply only to extraction of the source domain from the inputs; > naturally, if the inputs themselves are invalid or corrupt (e.g., a > user has clicked a link provided by a malicious entity in a phishing > attack), then the client might end up communicating with an > unexpected application service. >=20 > See also Section 4.3: >=20 > o For a reference identifier of type URI-ID, the DNS domain name > portion is the "reg-name" part of the "authority" component and > the application type portion is the scheme name matching the > [ABNF] "scheme" rule from [URI] (not including the ':' = separator). > As previously mentioned, this document specifies that a URI-ID > always contains an "authority" component whose "host" = subcomponent > contains a "reg-name". (Matching only the "reg-name" rule from > [URI] limits verification to DNS domain names, thereby > differentiating a URI-ID from a uniformResourceIdentifier entry > that contains an IP address or a mere host name, or that does not > contain an "authority" component at all.). Furthermore, note = that > extraction of the "reg-name" might necessitate normalization of > the URI (as explained in [URI]. As an example, a URI-ID of "sip: > voice.example.edu" would be split into a DNS domain name portion > of "voice.example.edu" and an application type of "sip" (mapping > to an application protocol of SIP as explained in [SIP-CERTS]). Most of that text is specification, not example. The example in 4.3 is = trivial in the sense that all that the source URI contained was the = scheme and the authority. The implementation basically had to cut out a = colon :-) >=20 > However, perhaps we need to say more in Section 4.2.1, including some > examples? I think 4.2.1 says the right things as far as the specification language = goes. Perhaps merely expanding the example in 4.3 bullet 4 to u say = something along the lines of "A SIP Address of Record of = "sip:user@voice.example.edu" would yield a DNS domain portion of = "voice.example.edu" and an application type of "sip", yielding a URI-ID = of "sip:voice.example.net" Alternately, a URI-ID example in 4.2.2 could work, although I realize = none of the other examples in that section start with the raw user = input.=20 From ben@nostrum.com Wed Dec 8 13:32: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 C25BE3A6988; Wed, 8 Dec 2010 13:32:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.372 X-Spam-Level: X-Spam-Status: No, score=-102.372 tagged_above=-999 required=5 tests=[AWL=0.228, BAYES_00=-2.599, SPF_PASS=-0.001, 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 9SYAP+qeWhTt; Wed, 8 Dec 2010 13:32:41 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 6275C3A687D; Wed, 8 Dec 2010 13:32:41 -0800 (PST) Received: from dn3-174.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id oB8LY7g8076334 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 8 Dec 2010 15:34:08 -0600 (CST) (envelope-from ben@nostrum.com) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Ben Campbell In-Reply-To: <4CFFE19F.1060603@KingsMountain.com> Date: Wed, 8 Dec 2010 15:34:06 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4CFFE19F.1060603@KingsMountain.com> To: =JeffH X-Mailer: Apple Mail (2.1082) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: draft-saintandre-tls-server-id-check.all@tools.ietf.org, General Area Review Team , certid@ietf.org Subject: Re: [certid] [Gen-art] Gen-ART LC Review of draft-saintandre-tls-server-id-check-11 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, 08 Dec 2010 21:32:42 -0000 On Dec 8, 2010, at 1:50 PM, =3DJeffH wrote: > >=20 > > stpete sez.. > >> In Section 4.2.1 we say: > >> > >> The inputs used by the client to construct its list of reference > >> identifiers might be a URI that a user has typed into an = interface > >> (e.g., an HTTPS URL for a web site), configured account = information > >> (e.g., the domain name of a particular host or URI used for > >> retrieving information or connecting to a network, which might be > >> different from the server portion of the user's account name), a > >> hyperlink in a web page that triggers a browser to retrieve a = media > >> object or script, or some other combination of information that = can > >> yield a source domain and a service type. > >> > >> The client might need to extract the source domain and service = type > >> from the input(s) it has received. The extracted data MUST = include > >> only information that can be securely parsed out of the inputs = (e.g., > >> extracting the fully-qualified DNS domain name from the = "authority" > >> component of a URI or extracting the service type from the scheme = of > ^^^^^^^^^^ >=20 > I suggest we change this to "deriving". >=20 >=20 WFM > >> a URI) or information for which the extraction is performed in a > >> manner that is not subject to subversion by network attackers = (e.g., > >> pulling the data from a delegated domain that is explicitly > >> established via client or system configuration, resolving the = data > >> via [DNSSEC], or obtaining the data from a third-party domain = mapping > >> service in which a human user has explicitly placed trust and = with > >> which the client communicates over a connection that provides = both > >> mutual authentication and integrity checking). These = considerations > >> apply only to extraction of the source domain from the inputs; > >> naturally, if the inputs themselves are invalid or corrupt (e.g., = a > >> user has clicked a link provided by a malicious entity in a = phishing > >> attack), then the client might end up communicating with an > >> unexpected application service. > >> > >> Do you feel we need to say more about how an application client > >> determines the source domain? Is there something special about SIP = AORs > >> that this document does not cover (but should be covering)? >=20 >=20 > BenC replies.. > > > > > I am suggesting a soup to nuts example of how a real world input = such as > > that gets converted to a resulting URI reference identity. >=20 >=20 > So after the second para quoted above (from [S4.2.1]) how 'bout we add = this.. >=20 >=20 > For example, given an input URI of = "sip:alice:pswd@example.net;transport=3Dtcp?subject=3Dproject%20x&priority= =3Durgent", the client derives the service type "sip" from the scheme, = and the domain name "example.net" from the authority component. Also, = given an input URI of "im:alice@example.net", the derived service type = is "sip" (since the "im" scheme is defined as an abstract scheme in the = SIP context by [SIP-IM] (RFC 3428)), and the domain name is again = "example.net". That's pretty much what I had in mind, although the URI is more complex = that you are likely to see as user input. just "sip:alice@example.net" = would probably get the idea across. >=20 >=20 > ? >=20 > =3DJeffH >=20 >=20 >=20 From ben@nostrum.com Wed Dec 8 13:38: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 D5DB43A698E; Wed, 8 Dec 2010 13:38:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.095 X-Spam-Level: X-Spam-Status: No, score=-102.095 tagged_above=-999 required=5 tests=[AWL=-0.095, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, SPF_PASS=-0.001, 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 LNHU0Yu6KbwB; Wed, 8 Dec 2010 13:38:04 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id E5ED43A6988; Wed, 8 Dec 2010 13:37:54 -0800 (PST) Received: from dn3-174.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id oB8LdMu3076714 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 8 Dec 2010 15:39:22 -0600 (CST) (envelope-from ben@nostrum.com) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Ben Campbell In-Reply-To: <4CFFE784.20302@stpeter.im> Date: Wed, 8 Dec 2010 15:39:21 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4CFFE19F.1060603@KingsMountain.com> <4CFFE784.20302@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1082) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: draft-saintandre-tls-server-id-check.all@tools.ietf.org, General Area Review Team , certid@ietf.org, =JeffH Subject: Re: [certid] [Gen-art] Gen-ART LC Review of draft-saintandre-tls-server-id-check-11 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, 08 Dec 2010 21:38:06 -0000 On Dec 8, 2010, at 2:16 PM, Peter Saint-Andre wrote: [...] >> For example, given an input URI of >> = "sip:alice:pswd@example.net;transport=3Dtcp?subject=3Dproject%20x&priority= =3Durgent", >> the client derives the service type "sip" from the scheme, and the >> domain name "example.net" from the authority component.=20 >=20 > Looks good. I love gnarly URIs. :) >=20 See my comment to Jeff. A simpler URI would be good enough, as long as = its got _something_ beyond just the scheme and authority parts. And we = should be careful with transport=3Dtcp lest someone ask why we are = connecting via TLS. How about just "sips:alice@example.net"? (the "sips" = scheme both shows that we intend to use TLS, and illustrates how a user = input scheme of "sips" might result in a reference id scheme of "sip".) >> Also, given an >> input URI of "im:alice@example.net", the derived service type is = "sip" >> (since the "im" scheme is defined as an abstract scheme in the SIP >> context by [SIP-IM] (RFC 3428)), and the domain name is again >> "example.net". >=20 > Well, the im: and pres: URIs can result in a derived service type of > "xmpp", too. It depends on what a service has deployed... >=20 If my SIP client derives an XMPP service, it will violate the principle = of least surprise :-) But on reflection, I think the "im" example may = delve to far into the esoteric even for me.=20 > http://tools.ietf.org/html/rfc3860 >=20 > http://www.iana.org/assignments/im-srv-labels/im-srv-labels.xhtml >=20 > Peter >=20 > --=20 > Peter Saint-Andre > https://stpeter.im/ >=20 >=20 >=20 > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art From stpeter@stpeter.im Wed Dec 8 13:42: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 8F3193A687D; Wed, 8 Dec 2010 13:42:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.394 X-Spam-Level: X-Spam-Status: No, score=-103.394 tagged_above=-999 required=5 tests=[AWL=1.205, BAYES_00=-2.599, GB_I_LETTER=-2, 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 mBMHKYl3TDbN; Wed, 8 Dec 2010 13:42:53 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id A15AD3A686B; Wed, 8 Dec 2010 13:42:52 -0800 (PST) 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 99A264009B; Wed, 8 Dec 2010 14:56:12 -0700 (MST) Message-ID: <4CFFFC32.2000806@stpeter.im> Date: Wed, 08 Dec 2010 14:44:18 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: =JeffH References: <4CFFD91A.2060808@KingsMountain.com> In-Reply-To: <4CFFD91A.2060808@KingsMountain.com> X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms050104060209080400010102" Cc: IETF cert-based identity , IETF Discussion List , draft-saintandre-tls-server-id-check.all@tools.ietf.org Subject: Re: [certid] Second Last Call: draft-saintandre-tls-server-id-check (...) to BCP 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, 08 Dec 2010 21:42:56 -0000 This is a cryptographically signed message in MIME format. --------------ms050104060209080400010102 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 12/8/10 12:14 PM, =3DJeffH wrote: > [ adding certid@ list ] >=20 > Thanks for the review SM. >=20 >> In Section 2.2: >> >> 'A "traditional domain name", i.e., a fully-qualified domain name >> or "FQDN" (see [DNS-CONCEPTS]) all of whose labels are "LDH >> labels" as defined in [IDNA-DEFS].' >> >> It would be better to reference RFC 1123 for LDH labels instead of >> RFC 5890 unless the authors would like to adopt a terminology that is >> specific to IDNA. >=20 > I looked into this in detail earlier this year -- it was discussed on > ietf@ (during the initial IETF LC for this spec), and this particular > issue resolution was summarized here (by John Klensin).. >=20 > Re: Last Call: draft-saintandre-tls-server-id-check > http://www.ietf.org/mail-archive/web/ietf/current/msg62601.html >=20 > In brief summary, RFCs {1034,1035,1123,2181} do not define > "letter-digit-hyphen" DNS name labels in a concisely referenceable > fashion, nor particularly clearly. >=20 > The IDNA specs have done the wider DNS-community a service by doing so,= > and at present the fashion in which "traditional domain name" is define= d > and cited is the best we can do. Given that IDNs are a deployed reality= , > every (new or updated) spec that discusses domain names going forward i= s > going to need to reference the IDNA specs in some fashion, and probably= > should simply use the LDH-Label, A-Label, and U-Label nomenclature. (IM= V) I agree with that assessment. >> In Section 3.1: >> >> "Unless a profile of this specification allows continued support >> for the wildcard character '*', the fully-qualified DNS domain >> name portion of a presented identifier SHOULD NOT contain the >> wildcard character, whether as the complete left-most label >> within the identifier (following the definition of "label" from >> [DNS], e.g., "*.example.com") or as a fragment thereof (e.g., >> *oo.example.com, f*o.example.com, or foo*.example.com)." >> >> If the presented identifier is a fully-qualified DNS domain name (I >> assume that means FQDN), the left-most label cannot be a wildcard >> character according to LDH rules. I suggest rewriting that as: >> >> Unless a profile of this specification allows continued support >> for the wildcard character '*', the domain name portion of >> a presented identifier SHOULD NOT contain the wildcard character >> (e.g., "*.example.com") or as a fragment thereof (e.g., >> *oo.example.com, f*o.example.com, or foo*.example.com). >=20 > while I agree with your subtle substitution of.. >=20 > "fully-qualified DNS domain name portion" >=20 > ..with.. >=20 > "domain name portion" Done. > ..however, I disagree with your further simplification of that paragrap= h > because we feel we need to supply the more detailed context. >=20 >=20 >=20 >> In Section 4.2.1: >> >> "The client might need to extract the source domain and service typ= e >> from the input(s) it has received. The extracted data MUST includ= e >> only information that can be securely parsed out of the inputs (e.= g., >> extracting the fully-qualified DNS domain name from the authority >> component of a URI or extracting the service type from the scheme = of >> a URI) or information for which the extraction is performed in a >> manner that is not subject to subversion by network attackers (e.g= =2E, >> pulling the data from a delegated domain that is explicitly >> established via client or system configuration, resolving the data= >> via [DNSSEC], or obtaining the data from a third-party domain mapp= ing >> service in which a human user has explicitly placed trust and with= >> which the client communicates over a connection that provides both= >> mutual authentication and integrity checking)." >> >> I read part of the above as meaning that data can only be extracted >> from DNS if the data has been resolved via DNSSEC. Is that the intent= ? >=20 > No, that is not the intent. We've further refined that paragraph as a > result of a concurrent discussion with Ben Campbell (on certid@) and > have this present working text.. >=20 > The client might need to extract the source domain and service type > from the input(s) it has received. The extracted data MUST include > only information that can be securely parsed out of the inputs (e.g.= , > extracting the fully-qualified DNS domain name from the "authority" > component of a URI or extracting the service type from the scheme of= > a URI) or information for which the extraction is performed in a > manner that is not subject to subversion by network attackers (e.g.,= > pulling the data from a delegated domain that is explicitly > established via client or system configuration, resolving the data > via [DNSSEC], or obtaining the data from a third-party domain mappin= g > service in which a human user has explicitly placed trust and with > which the client communicates over a connection that provides both > mutual authentication and integrity checking). These considerations= > apply only to extraction of the source domain from the inputs; > naturally, if the inputs themselves are invalid or corrupt (e.g., a > user has clicked a link provided by a malicious entity in a phishing= > attack), then the client might end up communicating with an > unexpected application service. >=20 >=20 >=20 >> Section 4.3 discusses about how to seek a match against the list of >> reference identifiers. I found the thread at >> http://www.ietf.org/mail-archive/web/certid/current/msg00318.html > informative. >> >> In Section 4.4.3: >> >> "A client employing this specification's rules MAY match the refere= nce >> identifier against a presented identifier whose DNS domain name >> portion contains the wildcard character '*' as part or all of a la= bel >> (following the definition of "label" from [DNS])" >> >> According to the definition of label in RFC 1035, the wildcard >> character cannot be part of a label. I suggest removing the last >> part of that sentence. >=20 > You mean removing the parenthetical "(following the definition of > "label" from [DNS])", yes? >=20 > In reviewing RFC 1035 I see your concern, tho we'd like to reference a > description of "label". I note that RFC 1034 [S3.1] seems to > appropriately supply this, so I propose we keep the parenthetical but > alter it to be.. >=20 > (following the description of labels and domain names in [DNS-CONCEPT= S]) Done. >> FWIW, RFC 4592 updates the wildcard >> definition in RFC 1034 and uses the term "asterisk label". >=20 > Yes, but that definition (and term) appears to be specific to underlyin= g > DNS internals, not to (pseudo) domain names as wielded (or "presented" > (eg in certs)) in other protocols. >=20 >=20 >> Was the comment about the security note ( >> http://www.ietf.org/mail-archive/web/certid/current/msg00427.html ) >> in Section 4.6.4 addressed? >=20 > Yes, we believe so. >=20 >=20 > thanks again for your review, Indeed. Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms050104060209080400010102 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/ jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q 7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo 98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR 6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV 0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD 0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri 2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6 wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1 nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2 gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1 My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo 6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3 GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6 2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4 TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0 ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+ 39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c 6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2 0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0 H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0 dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTIw ODIxNDQxOFowIwYJKoZIhvcNAQkEMRYEFDGp9KowI8RqylCoe8xsHue0LF9oMF8GCSqGSIb3 DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG 9w0BAQEFAASCAQBNx2pJET9NmKzBb9Fjk7x9z3UhfnVoE6q9x3KpzK72ZuCbyOPXHECd4O5+ zm3jwIuhRHdSTWEvN/BwO5z9xHgU4vY39Oo1leX99pIHJ5YPq+ItFycUVhVQeahWAtjuWxMx V7igVme9wkCG9BjIGGN66ZuQvvfiRCIg9bu0QkjtJnFF9O8H3yX87cgwWTIra/SIqDV9QgjU yqT9v788kJDcVBz+dc/5lwH6bf65f3Vs9cF6huUUiAVU/eZ04iUcKuiwc9ySIcuSou0DNhlx u7A8t2X/GccSB1De/sbf5I11oiG6yarLMa0iEUxN/f/1N2OqvjV5X84up7myth2DwbpaAAAA AAAA --------------ms050104060209080400010102-- From ben@estacado.net Wed Dec 8 13:39:02 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 A3C9B3A686B; Wed, 8 Dec 2010 13:39:02 -0800 (PST) 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=[AWL=0.001, 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 71UyHWV32i-2; Wed, 8 Dec 2010 13:39:00 -0800 (PST) Received: from estacado.net (estacado-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:266::2]) by core3.amsl.com (Postfix) with ESMTP id 76A5A3A687D; Wed, 8 Dec 2010 13:38:59 -0800 (PST) Received: from dn3-174.estacado.net (dn3-174.estacado.net [172.16.3.174]) (authenticated bits=0) by estacado.net (8.14.3/8.14.2) with ESMTP id oB8LePp3008538 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 8 Dec 2010 15:40:26 -0600 (CST) (envelope-from ben@estacado.net) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Ben Campbell In-Reply-To: <4CFFEE6B.4060306@KingsMountain.com> Date: Wed, 8 Dec 2010 15:40:20 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <758EE1BF-B829-4703-B647-27580FC64E28@estacado.net> References: <4CFFEE6B.4060306@KingsMountain.com> To: =JeffH X-Mailer: Apple Mail (2.1082) X-Mailman-Approved-At: Wed, 08 Dec 2010 13:43:10 -0800 Cc: draft-saintandre-tls-server-id-check.all@tools.ietf.org, General Area Review Team , certid@ietf.org Subject: Re: [certid] [Gen-art] Gen-ART LC Review of draft-saintandre-tls-server-id-check-11 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, 08 Dec 2010 21:39:03 -0000 On Dec 8, 2010, at 2:45 PM, =3DJeffH wrote: > > We can tweak it to: > > > > As an example, given an input URI of "sip:alice:pswd@ > > example.net;transport=3Dtcp?subject=3Dproject%20x&priority=3Durgent= ", the > > client derives the service type "sip" from the scheme and the = domain > > name "example.net" from the authority component. Also, given an > > input URI of "im:alice@example.net", the derived service type = might > > be "sip", depending on how the example.net service is deployed = (since > > the "im" scheme [CPIM] is defined as an abstract scheme in the = SIP > > context by [SIP-IM]), and the domain name would again be > > "example.net". >=20 > works for me. >=20 > someone just noted offlist that we should perhaps change the scheme of = the first URI to "sips". Heh--I just got finished typing a similar comment :-) >=20 > =3DJeffH >=20 > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art From stpeter@stpeter.im Wed Dec 8 13:45: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 534563A687D; Wed, 8 Dec 2010 13:45:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.204 X-Spam-Level: X-Spam-Status: No, score=-102.204 tagged_above=-999 required=5 tests=[AWL=-0.205, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, 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 dMoD7BcGIUZK; Wed, 8 Dec 2010 13:45:44 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 542633A686B; Wed, 8 Dec 2010 13:45:44 -0800 (PST) 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 9381B4009B; Wed, 8 Dec 2010 14:59:04 -0700 (MST) Message-ID: <4CFFFCDE.1030104@stpeter.im> Date: Wed, 08 Dec 2010 14:47:10 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: Ben Campbell References: <4CFFE19F.1060603@KingsMountain.com> <4CFFE784.20302@stpeter.im> In-Reply-To: X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090806010200050209010008" Cc: draft-saintandre-tls-server-id-check.all@tools.ietf.org, General Area Review Team , certid@ietf.org, =JeffH Subject: Re: [certid] [Gen-art] Gen-ART LC Review of draft-saintandre-tls-server-id-check-11 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, 08 Dec 2010 21:45:45 -0000 This is a cryptographically signed message in MIME format. --------------ms090806010200050209010008 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 12/8/10 2:39 PM, Ben Campbell wrote: >=20 > On Dec 8, 2010, at 2:16 PM, Peter Saint-Andre wrote: >=20 > [...] >=20 >>> For example, given an input URI of=20 >>> "sip:alice:pswd@example.net;transport=3Dtcp?subject=3Dproject%20x&pri= ority=3Durgent", >>> >>>=20 the client derives the service type "sip" from the scheme, and the >>> domain name "example.net" from the authority component. >>=20 >> Looks good. I love gnarly URIs. :) >>=20 >=20 > See my comment to Jeff. A simpler URI would be good enough, as long > as its got _something_ beyond just the scheme and authority parts. > And we should be careful with transport=3Dtcp lest someone ask why we > are connecting via TLS. How about just "sips:alice@example.net"? (the > "sips" scheme both shows that we intend to use TLS, and illustrates > how a user input scheme of "sips" might result in a reference id > scheme of "sip".) WFM. >>> Also, given an input URI of "im:alice@example.net", the derived >>> service type is "sip" (since the "im" scheme is defined as an >>> abstract scheme in the SIP context by [SIP-IM] (RFC 3428)), and >>> the domain name is again "example.net". >>=20 >> Well, the im: and pres: URIs can result in a derived service type >> of "xmpp", too. It depends on what a service has deployed... >>=20 >=20 > If my SIP client derives an XMPP service, it will violate the > principle of least surprise :-) But on reflection, I think the "im" > example may delve to far into the esoteric even for me. Me, too. And I've already noted that the "im" and "pres" haven't been deployed widely, if at all. Striking that sentence seems sensible. Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms090806010200050209010008 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/ jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q 7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo 98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR 6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV 0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD 0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri 2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6 wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1 nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2 gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1 My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo 6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3 GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6 2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4 TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0 ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+ 39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c 6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2 0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0 H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0 dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTIw ODIxNDcxMFowIwYJKoZIhvcNAQkEMRYEFH6OPlhIaQRwX8n194YN+F6XQz/TMF8GCSqGSIb3 DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG 9w0BAQEFAASCAQCijHsz8D1Flunq7cj0bCXEapTjy7ZkB/lm74S1MmUCk42H6Y4sNKYnoXH1 r31Nc+zoIid2WSCCx87XNb7+tYPbKh8pb8E+K6OmuZzUOp+zgMuab8mqFWgIp69DFmR2PBAa gmCvQSB6PNKpBSRqAdkm/aMMMcN1fr0Toihoxi7NIIsToyAjPiuI8wRx0dkjtwQdC9Z/XmJK Y6UPokRSOKNBNI+iEaYWo7jsMRVZ/cTka+9ClxVDaqwEQecKMzRPkcElJ1wGd4hDwhF+0unZ WxWYv8YwLdGaNkqQh9nJq0zZpjhdCqeSypfBUPXhO2r849ZSfk6iSLOh+1kr3MXqkJpBAAAA AAAA --------------ms090806010200050209010008-- From stpeter@stpeter.im Wed Dec 8 14:10: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 014DE3A69A2; Wed, 8 Dec 2010 14:10:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.487 X-Spam-Level: X-Spam-Status: No, score=-102.487 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, 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 pxIJ5YZBF+3s; Wed, 8 Dec 2010 14:10:27 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id CDF7A3A689F; Wed, 8 Dec 2010 14:10:24 -0800 (PST) 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 9922A4009B; Wed, 8 Dec 2010 15:23:30 -0700 (MST) Message-ID: <4D000298.20002@stpeter.im> Date: Wed, 08 Dec 2010 15:11:36 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: =JeffH References: <4CFFF2D8.4070408@KingsMountain.com> In-Reply-To: <4CFFF2D8.4070408@KingsMountain.com> X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070109040702000104090304" Cc: Ben Campbell , General Area Review Team , IETF cert-based identity , Paul Hoffman , draft-saintandre-tls-server-id-check.all@tools.ietf.org Subject: Re: [certid] Gen-ART LC Review of draft-saintandre-tls-server-id-check-11 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, 08 Dec 2010 22:10:39 -0000 This is a cryptographically signed message in MIME format. --------------ms070109040702000104090304 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 12/8/10 2:04 PM, =3DJeffH wrote: > stpete replied.. >> >> On 12/7/10 8:01 AM, Paul Hoffman wrote: >>> [[ Much abbreviated ]] >>> >>> At 9:10 PM -0700 12/6/10, Peter Saint-Andre wrote: >>>>>>> -- 3.1, rule 6: >>>>>>> >>>>>>> Can you motivate why this is not a MUST NOT? >>>>> The reason for allowing this wiggle-room is that (for better or > worse).. >>>>> >>>>> 1. the CA/Browser Forum Extended Validation (EV) Certificate > Guidelines >>>>> explicitly allow for multiple CN-IDs >>>>> >>>>> 2. It's a not-totally-uncommon current practice to have certs > that do >>>>> have >>>>> mutiple CN-IDs, eg from Comodo (whether EV or DV (domain > valivdated)). >>>>> >>>>> 3. Virtual hosting multiple distinct-domain TLS servers on one > entity is >>>>> difficult today if one desires wide desktop client support > because >>>>> a certain vendor's older-but-still-widely-deployed-OS does not= > (yet?) >>>>> support the TLS Server Name Indication extension. Thus having = one >>>>> cert with all the domains jammed in it (as either/both CN-IDs > or/and >>>>> DNS-IDs) is a workaround (eg Content Delivery Networks use thi= s). >>>>> >>>>> >>>>> So some argue that if we MUST NOT multiple CN-IDs at this point, it= is >>>>> flying in the face of present reality and might contribute to > acquiring >>>>> an attained reputation for this BCP that is lower than we desire. >>>>> >>>>> There is also concern on the part of CA folk about client-side TLS > libs >>>>> and their support for name matching (ie some (old?) one(s) will onl= y >>>>> match on CN-ID). >>>>> >>>>> For a CA perspective on all the above, see... >>>>> >>>>> Re: [certid] weird CN-IDs (subjectCommonName) in SSL Labs Survey Da= ta >>>>> http://www.ietf.org/mail-archive/web/certid/current/msg00502.html >>>> >>>> +1 to all that. >>> >>> Putting an explanation such as the above in the document will help > future >>> IETFs to decide when to make this a MUST NOT. It might also help the > CA/Browser >>> Forum and specific CAs see that they should stop doing this ASAP, and= > maybe >>> even convince a particular legacy OS vendor to support TLS SNI. >> >> Sigh. I don't particularly want to add a long informational note that >> qualifies eight words in the spec, but you're right. :) >=20 > agreed. Possible text for the Security Considerations: ### 5.4. Multiple Identifiers This specification allows multiple DNS-IDs, SRV-IDs, or URI-IDs in a certificate, but discourages multiple CN-IDs. The inclusion in the Common Name of multiple strings whose form matches that of a fully- qualified DNS domain name (e.g., "www.example.com") makes it more difficult to parse the Common Name and increases the likelihood of false positives in the identity verification process. Although it would be preferable to forbid multiple CN-IDs entirely, there are several reasons why this specification states that they SHOULD NOT (instead of MUST NOT) be included: o At least one significant technology community of interest explicitly allows multiple CN-IDs [EV-CERTS]. o At least one significant certification authority is known to issue certificates containing multiple CN-IDs. o Many service providers often deem inclusion of multiple CN-IDs necessary in "virtual hosting" environments because at least one widely-deployed operating system does not yet support the Server Name Indication extension [TLS-EXT] It is hoped that the recommendation in this specification can be further tightened in the future. ### To be referenced from bullet #6 in Section 3.1: 6. The certificate MAY contain more than one DNS-ID, SRV-ID, or URI-ID (but SHOULD NOT contain more than one CN-ID, as further explained under Section 5.4). /psa --------------ms070109040702000104090304 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/ jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q 7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo 98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR 6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV 0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD 0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri 2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6 wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1 nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2 gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1 My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo 6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3 GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6 2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4 TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0 ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+ 39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c 6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2 0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0 H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0 dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTIw ODIyMTEzNlowIwYJKoZIhvcNAQkEMRYEFGL6dnvB2SYkPLnxUaUN/lfqHhg5MF8GCSqGSIb3 DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG 9w0BAQEFAASCAQCl9JgXjwO8VPf+HE0Sa1E+XhNUuZFRGIggt10qmoDlVBhyVtSEn81lIlCa 5aRjrRBctxnImuh2swiLis2Qgz2nsNAXf+wo/YUthfKV+CSH0jDBtPcKrWAhvpdxWvFm1PYk 8leDi53pP4ywfGhU3Vc+LlruX6+kpsKRvv3FKVtePFYUX+Ooe19cbekF4cwf8vnnp5gzGbBl EwfKgi7rGdqMWv6BEgucCRFP2hw4OEtOrM5FxTAQUaUDx0RIA+ZjamIZqMUg1fDszpVG3rvy 8FtxGbh0fBXlKWJ7B4YxrpbfbASfX/4cxoM34zIwpgj5hCodQqMEzB10xttyWWPKRHycAAAA AAAA --------------ms070109040702000104090304-- From ben@nostrum.com Wed Dec 8 14:17: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 E548F3A69A7; Wed, 8 Dec 2010 14:17:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.386 X-Spam-Level: X-Spam-Status: No, score=-102.386 tagged_above=-999 required=5 tests=[AWL=0.214, BAYES_00=-2.599, SPF_PASS=-0.001, 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 6aEWaq0CJD2J; Wed, 8 Dec 2010 14:17:52 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 095CF3A6999; Wed, 8 Dec 2010 14:17:51 -0800 (PST) Received: from dn3-174.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id oB8MJG5p079947 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 8 Dec 2010 16:19:16 -0600 (CST) (envelope-from ben@nostrum.com) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Ben Campbell In-Reply-To: <4D000298.20002@stpeter.im> Date: Wed, 8 Dec 2010 16:19:16 -0600 Content-Transfer-Encoding: 7bit Message-Id: <7CDA6BC3-50D9-48B1-8BF6-638BAEF63891@nostrum.com> References: <4CFFF2D8.4070408@KingsMountain.com> <4D000298.20002@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1082) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: draft-saintandre-tls-server-id-check.all@tools.ietf.org, General Area Review Team , IETF cert-based identity , Paul Hoffman , =JeffH Subject: Re: [certid] [Gen-art] Gen-ART LC Review of draft-saintandre-tls-server-id-check-11 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, 08 Dec 2010 22:17:54 -0000 WFM On Dec 8, 2010, at 4:11 PM, Peter Saint-Andre wrote: > On 12/8/10 2:04 PM, =JeffH wrote: >> stpete replied.. >>> >>> On 12/7/10 8:01 AM, Paul Hoffman wrote: >>>> [[ Much abbreviated ]] >>>> >>>> At 9:10 PM -0700 12/6/10, Peter Saint-Andre wrote: >>>>>>>> -- 3.1, rule 6: >>>>>>>> >>>>>>>> Can you motivate why this is not a MUST NOT? >>>>>> The reason for allowing this wiggle-room is that (for better or >> worse).. >>>>>> >>>>>> 1. the CA/Browser Forum Extended Validation (EV) Certificate >> Guidelines >>>>>> explicitly allow for multiple CN-IDs >>>>>> >>>>>> 2. It's a not-totally-uncommon current practice to have certs >> that do >>>>>> have >>>>>> mutiple CN-IDs, eg from Comodo (whether EV or DV (domain >> valivdated)). >>>>>> >>>>>> 3. Virtual hosting multiple distinct-domain TLS servers on one >> entity is >>>>>> difficult today if one desires wide desktop client support >> because >>>>>> a certain vendor's older-but-still-widely-deployed-OS does not >> (yet?) >>>>>> support the TLS Server Name Indication extension. Thus having one >>>>>> cert with all the domains jammed in it (as either/both CN-IDs >> or/and >>>>>> DNS-IDs) is a workaround (eg Content Delivery Networks use this). >>>>>> >>>>>> >>>>>> So some argue that if we MUST NOT multiple CN-IDs at this point, it is >>>>>> flying in the face of present reality and might contribute to >> acquiring >>>>>> an attained reputation for this BCP that is lower than we desire. >>>>>> >>>>>> There is also concern on the part of CA folk about client-side TLS >> libs >>>>>> and their support for name matching (ie some (old?) one(s) will only >>>>>> match on CN-ID). >>>>>> >>>>>> For a CA perspective on all the above, see... >>>>>> >>>>>> Re: [certid] weird CN-IDs (subjectCommonName) in SSL Labs Survey Data >>>>>> http://www.ietf.org/mail-archive/web/certid/current/msg00502.html >>>>> >>>>> +1 to all that. >>>> >>>> Putting an explanation such as the above in the document will help >> future >>>> IETFs to decide when to make this a MUST NOT. It might also help the >> CA/Browser >>>> Forum and specific CAs see that they should stop doing this ASAP, and >> maybe >>>> even convince a particular legacy OS vendor to support TLS SNI. >>> >>> Sigh. I don't particularly want to add a long informational note that >>> qualifies eight words in the spec, but you're right. :) >> >> agreed. > > Possible text for the Security Considerations: > > ### > > 5.4. Multiple Identifiers > > This specification allows multiple DNS-IDs, SRV-IDs, or URI-IDs in a > certificate, but discourages multiple CN-IDs. The inclusion in the > Common Name of multiple strings whose form matches that of a fully- > qualified DNS domain name (e.g., "www.example.com") makes it more > difficult to parse the Common Name and increases the likelihood of > false positives in the identity verification process. Although it > would be preferable to forbid multiple CN-IDs entirely, there are > several reasons why this specification states that they SHOULD NOT > (instead of MUST NOT) be included: > > o At least one significant technology community of interest > explicitly allows multiple CN-IDs [EV-CERTS]. > > o At least one significant certification authority is known to issue > certificates containing multiple CN-IDs. > > o Many service providers often deem inclusion of multiple CN-IDs > necessary in "virtual hosting" environments because at least one > widely-deployed operating system does not yet support the Server > Name Indication extension [TLS-EXT] > > It is hoped that the recommendation in this specification can be > further tightened in the future. > > ### > > To be referenced from bullet #6 in Section 3.1: > > 6. The certificate MAY contain more than one DNS-ID, SRV-ID, or > URI-ID (but SHOULD NOT contain more than one CN-ID, as further > explained under Section 5.4). > > /psa > > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art From Jeff.Hodges@KingsMountain.com Wed Dec 8 14:46: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 767E23A69AE for ; Wed, 8 Dec 2010 14:46:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.086 X-Spam-Level: X-Spam-Status: No, score=-102.086 tagged_above=-999 required=5 tests=[AWL=0.179, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 j1uWEO8-CDXg for ; Wed, 8 Dec 2010 14:46:54 -0800 (PST) Received: from cpoproxy3-pub.bluehost.com (cpoproxy3-pub.bluehost.com [67.222.54.6]) by core3.amsl.com (Postfix) with SMTP id 66DEB3A69A9 for ; Wed, 8 Dec 2010 14:46:54 -0800 (PST) Received: (qmail 3424 invoked by uid 0); 8 Dec 2010 22:48:21 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by cpoproxy3.bluehost.com with SMTP; 8 Dec 2010 22:48:21 -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=VyQHASB1Pq7+CnUwhmGyMSHrlkM3fnIHURgTqeo4TBpwx5TzQHFMFU5i+qtM66r661wdn5rQZb/iaTjrqMFLZp5ECFMcSVGojN+KenZreOtx+Y7YiG8cPPBAiMFTXhnv; 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 1PQSo9-0000jR-M6; Wed, 08 Dec 2010 15:48:21 -0700 Message-ID: <4D000B33.2050405@KingsMountain.com> Date: Wed, 08 Dec 2010 14:48:19 -0800 From: =JeffH User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: Paul Hoffman , Ben Campbell , General Area Review Team , IETF cert-based identity , draft-saintandre-tls-server-id-check.all@tools.ietf.org 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] Gen-ART LC Review of draft-saintandre-tls-server-id-check-11 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, 08 Dec 2010 22:46:55 -0000 > Possible text for the Security Considerations: > > ### > > 5.4. Multiple Identifiers > > This specification allows multiple DNS-IDs, SRV-IDs, or URI-IDs in a > certificate, but discourages multiple CN-IDs. The inclusion in the > Common Name of multiple strings whose form matches that of a fully- > qualified DNS domain name (e.g., "www.example.com") makes it more > difficult to parse the Common Name and increases the likelihood of > false positives in the identity verification process. Although it > would be preferable to forbid multiple CN-IDs entirely, there are > several reasons why this specification states that they SHOULD NOT > (instead of MUST NOT) be included: > > o At least one significant technology community of interest > explicitly allows multiple CN-IDs [EV-CERTS]. > > o At least one significant certification authority is known to issue > certificates containing multiple CN-IDs. > > o Many service providers often deem inclusion of multiple CN-IDs > necessary in "virtual hosting" environments because at least one > widely-deployed operating system does not yet support the Server > Name Indication extension [TLS-EXT] > > It is hoped that the recommendation in this specification can be > further tightened in the future. > > ### > > To be referenced from bullet #6 in Section 3.1: > > 6. The certificate MAY contain more than one DNS-ID, SRV-ID, or > URI-ID (but SHOULD NOT contain more than one CN-ID, as further > explained under Section 5.4). in general looks good to me, thanks. However, I'd alter the first sentence to s/allows/accommodates/, and in 2nd sentence s/discourages/explicitly discourages/. I'd alter the last sentence of 1st para s/reasons/reasons at this time/. And in terms of this.. The inclusion of multiple strings whose form matches that of a fully-qualified DNS domain name (e.g., "www.example.com") makes it more difficult to parse the Common Name and therefore increases the likelihood of false positives in the identity verification process. ..well, no, it doesn't make it more difficult to parse, and "it" is the Subject, not "the CN". There's multiple CN= AVAs in the Subject, but parsing them out is simple. I guess I'd just delete that entire middle sentence "The inclusion of...process." =JeffH From stpeter@stpeter.im Wed Dec 8 14:49:54 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 1FC2D3A69AD; Wed, 8 Dec 2010 14:49:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.495 X-Spam-Level: X-Spam-Status: No, score=-102.495 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, 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 InbyzziXw+8s; Wed, 8 Dec 2010 14:49:53 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id C03A93A69A9; Wed, 8 Dec 2010 14:49:52 -0800 (PST) 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 01B814009B; Wed, 8 Dec 2010 16:03:12 -0700 (MST) Message-ID: <4D000BE6.50208@stpeter.im> Date: Wed, 08 Dec 2010 15:51:18 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: =JeffH References: <4D000B33.2050405@KingsMountain.com> In-Reply-To: <4D000B33.2050405@KingsMountain.com> X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms060103000604090804010803" Cc: Ben Campbell , General Area Review Team , IETF cert-based identity , Paul Hoffman , draft-saintandre-tls-server-id-check.all@tools.ietf.org Subject: Re: [certid] Gen-ART LC Review of draft-saintandre-tls-server-id-check-11 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, 08 Dec 2010 22:49:54 -0000 This is a cryptographically signed message in MIME format. --------------ms060103000604090804010803 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 12/8/10 3:48 PM, =3DJeffH wrote: >> Possible text for the Security Considerations: >> >> ### >> >> 5.4. Multiple Identifiers >> >> This specification allows multiple DNS-IDs, SRV-IDs, or URI-IDs in = a >> certificate, but discourages multiple CN-IDs. The inclusion in the= >> Common Name of multiple strings whose form matches that of a fully-= >> qualified DNS domain name (e.g., "www.example.com") makes it more >> difficult to parse the Common Name and increases the likelihood of >> false positives in the identity verification process. Although it >> would be preferable to forbid multiple CN-IDs entirely, there are >> several reasons why this specification states that they SHOULD NOT >> (instead of MUST NOT) be included: >> >> o At least one significant technology community of interest >> explicitly allows multiple CN-IDs [EV-CERTS]. >> >> o At least one significant certification authority is known to iss= ue >> certificates containing multiple CN-IDs. >> >> o Many service providers often deem inclusion of multiple CN-IDs >> necessary in "virtual hosting" environments because at least one= >> widely-deployed operating system does not yet support the Server= >> Name Indication extension [TLS-EXT] >> >> It is hoped that the recommendation in this specification can be >> further tightened in the future. >> >> ### >> >> To be referenced from bullet #6 in Section 3.1: >> >> 6. The certificate MAY contain more than one DNS-ID, SRV-ID, or >> URI-ID (but SHOULD NOT contain more than one CN-ID, as further >> explained under Section 5.4). >=20 >=20 > in general looks good to me, thanks. >=20 > However, I'd alter the first sentence to s/allows/accommodates/, and i= n > 2nd sentence s/discourages/explicitly discourages/. >=20 > I'd alter the last sentence of 1st para s/reasons/reasons at this time/= =2E Agreed, and fixed. > And in terms of this.. >=20 > The inclusion of > multiple strings whose form matches that of a fully-qualified DNS > domain name (e.g., "www.example.com") makes it more difficult to > parse the Common Name and therefore increases the likelihood of fal= se > positives in the identity verification process. >=20 >=20 > ..well, no, it doesn't make it more difficult to parse, and "it" is the= > Subject, not "the CN". There's multiple CN=3D AVAs in the Subject, but > parsing > them out is simple. I guess I'd just delete that entire middle sentenc= e > "The > inclusion of...process." Well, since this text is in the security considerations section, presumably we need to provide some security-related justification for saying you SHOULD NOT include multiple CN-IDs, instead of mere aesthetic preference. :) Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms060103000604090804010803 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/ jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q 7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo 98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR 6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV 0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD 0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri 2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6 wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1 nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2 gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1 My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo 6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3 GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6 2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4 TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0 ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+ 39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c 6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2 0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0 H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0 dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTIw ODIyNTExOFowIwYJKoZIhvcNAQkEMRYEFF/QjC1/2FiWYFEJanZMfuTBnjTHMF8GCSqGSIb3 DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG 9w0BAQEFAASCAQBFHJ2HXHopy2U1PXmk0UzOSvnso4Kso3kXI6IVH8eogROPjXJfB8ICMj7h UfEHdQgUsvHJt/lHsD8vWVKBtX98bvtLT6oDQLBEi/0s0yQcR0Lesvq/4cbm0ExsM85P1JTh xfjm4TcM1hrSGubJ4xTlCKQikyHVXMGSuhpiVASbqFhv+aqZ3mQSzF/PqXkVimNgnq1T0lAp gSuXpkEkMJ2NqMa2zJLuSgXiEwFy1uzg7S3RcJbZ+MGHIay0ZTLWACW4E+z7K3bpbjPVoWlI SQrthaMK5+5yW0nIGxOVa4Q3Z5sv6SXy9xRNbeScNtee6sD7G0nj9FhoQ+nLcmeB3lcCAAAA AAAA --------------ms060103000604090804010803-- From Jeff.Hodges@KingsMountain.com Wed Dec 8 14:51: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 622D928C0CF for ; Wed, 8 Dec 2010 14:51:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.073 X-Spam-Level: X-Spam-Status: No, score=-101.073 tagged_above=-999 required=5 tests=[AWL=-0.774, BAYES_00=-2.599, MANGLED_LIST=2.3, 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 fQGYts27mbtL for ; Wed, 8 Dec 2010 14:51:12 -0800 (PST) Received: from oproxy1-pub.bluehost.com (oproxy1-pub.bluehost.com [66.147.249.253]) by core3.amsl.com (Postfix) with SMTP id E6EAA3A69A9 for ; Wed, 8 Dec 2010 14:51:11 -0800 (PST) Received: (qmail 22001 invoked by uid 0); 8 Dec 2010 22:52:39 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy1.bluehost.com.bluehost.com with SMTP; 8 Dec 2010 22:52:39 -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:CC:Subject:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=fWjsQrcbvG6cX9jKG7SE3lCTz8Ty0EN5Mi1cXqL+6GGESOvpThL7lB5KMDiQNKD5uQg3wl2gsy0Q5Gl2z69AGc5guF48Z4A0qJLL4Y3XhqD/atNgupWNp98L7+sThz4b; 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 1PQSsJ-0004um-0J; Wed, 08 Dec 2010 15:52:39 -0700 Message-ID: <4D000C34.5070008@KingsMountain.com> Date: Wed, 08 Dec 2010 14:52:36 -0800 From: =JeffH User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: Peter Saint-Andre 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} Cc: draft-saintandre-tls-server-id-check.all@tools.ietf.org, General Area Review Team , certid@ietf.org Subject: Re: [certid] Gen-ART LC Review of draft-saintandre-tls-server-id-check-11 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, 08 Dec 2010 22:51:13 -0000 see way below... PeterSA wrote on Wed, 08 Dec 2010 07:54:52 -0700 (06:54 PST) > > On 12/8/10 7:37 AM, Ben Campbell wrote: >> >> >> On Dec 8, 2010, at 7:10 AM, Peter Saint-Andre >> wrote: >> >>> On 12/7/10 10:45 PM, Ben Campbell wrote: >>>> >>>> On Dec 7, 2010, at 11:12 PM, Peter Saint-Andre wrote: >>>> >>>>> On 12/7/10 6:35 PM, Ben Campbell wrote: >>>>>> >>>>>> On Dec 6, 2010, at 7:00 PM, =JeffH wrote: >>>>>> >>>>>>> Peter Saint-Andre replied.. >>>>>>>> >>>>>>>> On 12/3/10 2:24 PM, "Ben Campbell" >>>>>>>> wrote: >>>>> >>>>> >>>>> >>>>>>>>> -- 3.1, 1st paragraph: >>>>>>>>> >>>>>>>>> It's probably worth emphasizing that the rules are >>>>>>>>> often cumulative. I think someone thinking about these >>>>>>>>> for the first time might not grasp that until they see >>>>>>>>> examples later in the doc. >>>>>>>> >>>>>>>> I've added the second sentence to this paragraph: >>>>>>>> >>>>>>>> When a certification authority issues a certificate based >>>>>>>> on the fully-qualified DNS domain name at which the >>>>>>>> application service provider will provide the relevant >>>>>>>> application, the following rules apply to the >>>>>>>> representation of application service identities. The >>>>>>>> reader needs to be aware that some of these rules are >>>>>>>> cumulative and can interact in important ways that are >>>>>>>> illustrated later in this document. >>>>>>> >>>>>>> LGTM. >>>>>> >>>>>> WFM >>>>>> >>>>>> In fact, as I was re-reading RFC 5922, it occurred to me to >>>>>> wonder if people need guidance one way or another on the idea >>>>>> of "multi-purpose" certs that might have any number of >>>>>> subjectAltName entries for different purposes. I'm talking >>>>>> about virtual domain hosting, or multi-protocol hosts. I >>>>>> assume in the latter case, you would expect a host to use >>>>>> different certs for different protocols. In the first case, >>>>>> is their any guidance to give. I can't remember, do you >>>>>> mention the TLS server_name extension? >>>>>> >>>>>> (I don't mean to suggest any real action here--just thinking >>>>>> out loud about something that would have been much better to >>>>>> bring up well before IETF LC. :-) ) >>>>> >>>>> Those scenarios are important, but IMHO how the server >>>>> determines which certificate to present (e.g., based on the SNI >>>>> or something else, such as the 'to' address on an XMPP stream >>>>> header) is something that an application protocol specification >>>>> needs to define. >>>> >>>> Agreed. Does this draft need to say that, or do we just take it >>>> as given? >>> >>> I think it's appropriate to add a few words about that. I >>> suggest... >>> >>> 1.1 >>> >>> ... When a client connects to an application service using >>> Transport Layer Security [TLS] or Datagram Transport Layer Security >>> [DTLS], it references some notion of the server's identity while >>> attempting to establish a secure connection (e.g., "the website at >>> example.com") and typically specifies at least the DNS domain name >>> with which it is trying to communicate (e.g., using a Server Name >>> Indication during TLS negotiation as described in [TLS-EXT]). >>> >>> 1.5 >>> >>> presented identifier: An identifier that is presented by a server >>> to a client within a PKIX certificate when the client attempts to >>> establish a secure connection with the server; the certificate can >>> include one or more presented identifiers of different types, and >>> the certificate presented is typically based on a DNS domain name >>> specified by the client when initiating communication (e.g., using >>> a Server Name Indication during TLS negotiation as described in >>> [TLS-EXT]). >>> >> >> Do you think server_name extension use is actually common enough to >> call typical? I'm not saying it's not--I don't really know one way or >> another. Otherwise, WFM. I don't think the TLS server_name extension (aka SNI) is in common enough use yet to call it "typical". There's a certain still-widely-deployed version of a certain desktop OS that doesn't support it, unfortunately. > We could say "and if the server hosts more than one domain then the > certificate presented is typically based..." Upon re-reading what we presently have in -11 for [S1.1], I don't think we need to introduce in that intro paragraph the notion of disambiguating names in a multi-domain situation. I'd leave that para as-is. in terms of the defn for "presented identifier" in [S1.5], I'd update it like so (I don't think mentioning SNI is reasonable in that defn proper).. presented identifier: An identifier that is presented by a server to a client within a PKIX certificate when the client attempts to establish a secure connection with the server; the certificate can include one or more presented identifiers of different types, and if the server hosts more than one domain then the certificate might present distinct identifiers for each domain. I'm wondering if we ought to add an "implementation note" at the end of [S3.1] where we mention why one might have a cert with multiple presented identifiers or a client may employ SNI. Implementation Note: A given application service may be addressed by multiple domain names for a variety of reasons. In the default [TLS] handshake exchange, there is no indication by the client as to the domain name the client trying to connect to, and the TLS server returns only one certificate for itself. Thus absent an extension to [TLS], a typical workaround used to facilitate mapping an application service to multiple domain names is to embed the said domain names into the returned application service certificate. Another approach, more recent and formally specified, is for the client to use the TLS "Server Name Indication" extension, when sending the client_hello message, stipulating the domain name the client used to connect with the application service. The application service can then return the appropriate certificate in its Certificate message. This latter certificate could thus contain a single domain name. of course, the FDA notes that the above will require generous wordsmithing before use. =JeffH From Jeff.Hodges@KingsMountain.com Wed Dec 8 14:55:21 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 4BEAF3A69AE for ; Wed, 8 Dec 2010 14:55:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.021 X-Spam-Level: X-Spam-Status: No, score=-102.021 tagged_above=-999 required=5 tests=[AWL=0.244, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 MyFeJd2mn92O for ; Wed, 8 Dec 2010 14:55:20 -0800 (PST) Received: from oproxy3-pub.bluehost.com (oproxy3-pub.bluehost.com [69.89.21.8]) by core3.amsl.com (Postfix) with SMTP id 87FB83A69B1 for ; Wed, 8 Dec 2010 14:55:20 -0800 (PST) Received: (qmail 8240 invoked by uid 0); 8 Dec 2010 22:56:46 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy3.bluehost.com with SMTP; 8 Dec 2010 22:56:46 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kingsmountain.com; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=Yg3U+ExOwtArmPYNc3e5HJeEL1RoNBka8Eer7Ihp9kwNnIk22pYXjkAM2l//0ro4PVOqkuWxM99ExCspowQey3KJUmRCr8lRImJWP9L4xeeDR119gDTVQ4GFfZQwTS6M; 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 1PQSwI-0001kG-N4; Wed, 08 Dec 2010 15:56:46 -0700 Message-ID: <4D000D2C.6060703@KingsMountain.com> Date: Wed, 08 Dec 2010 14:56:44 -0800 From: =JeffH User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: Peter Saint-Andre 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} Cc: draft-saintandre-tls-server-id-check.all@tools.ietf.org, General Area Review Team , certid@ietf.org Subject: Re: [certid] Gen-ART LC Review of draft-saintandre-tls-server-id-check-11 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, 08 Dec 2010 22:55:21 -0000 > I'm wondering if we ought to add an "implementation note" at the end of > [S3.1] where we mention why one might have a cert with multiple presented > identifiers or a client may employ SNI. oh, and refer to said impl note from bullet (6). =JeffH From stpeter@stpeter.im Wed Dec 8 15:54: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 9E4533A68D4; Wed, 8 Dec 2010 15:54:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.353 X-Spam-Level: X-Spam-Status: No, score=-101.353 tagged_above=-999 required=5 tests=[AWL=-1.054, BAYES_00=-2.599, MANGLED_LIST=2.3, 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 jIF7x6ARQK4j; Wed, 8 Dec 2010 15:54:06 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 02A193A68BA; Wed, 8 Dec 2010 15:54:06 -0800 (PST) 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 079BE4009B; Wed, 8 Dec 2010 17:07:25 -0700 (MST) Message-ID: <4D001AF2.7010000@stpeter.im> Date: Wed, 08 Dec 2010 16:55:30 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: =JeffH References: <4D000C34.5070008@KingsMountain.com> In-Reply-To: <4D000C34.5070008@KingsMountain.com> X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms030507050802060003090109" Cc: draft-saintandre-tls-server-id-check.all@tools.ietf.org, General Area Review Team , certid@ietf.org Subject: Re: [certid] Gen-ART LC Review of draft-saintandre-tls-server-id-check-11 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, 08 Dec 2010 23:54:09 -0000 This is a cryptographically signed message in MIME format. --------------ms030507050802060003090109 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable And the wordsmithing continues... On 12/8/10 3:52 PM, =3DJeffH wrote: > see way below... >=20 > PeterSA wrote on Wed, 08 Dec 2010 07:54:52 -0700 (06:54 PST) >> >> On 12/8/10 7:37 AM, Ben Campbell wrote: >>> >>> >>> On Dec 8, 2010, at 7:10 AM, Peter Saint-Andre >>> wrote: >>> >>>> On 12/7/10 10:45 PM, Ben Campbell wrote: >>>>> >>>>> On Dec 7, 2010, at 11:12 PM, Peter Saint-Andre wrote: >>>>> >>>>>> On 12/7/10 6:35 PM, Ben Campbell wrote: >>>>>>> >>>>>>> On Dec 6, 2010, at 7:00 PM, =3DJeffH wrote: >>>>>>> >>>>>>>> Peter Saint-Andre replied.. >>>>>>>>> >>>>>>>>> On 12/3/10 2:24 PM, "Ben Campbell" >>>>>>>>> wrote: >>>>>> >>>>>> >>>>>> >>>>>>>>>> -- 3.1, 1st paragraph: >>>>>>>>>> >>>>>>>>>> It's probably worth emphasizing that the rules are >>>>>>>>>> often cumulative. I think someone thinking about these >>>>>>>>>> for the first time might not grasp that until they see >>>>>>>>>> examples later in the doc. >>>>>>>>> >>>>>>>>> I've added the second sentence to this paragraph: >>>>>>>>> >>>>>>>>> When a certification authority issues a certificate based >>>>>>>>> on the fully-qualified DNS domain name at which the >>>>>>>>> application service provider will provide the relevant >>>>>>>>> application, the following rules apply to the >>>>>>>>> representation of application service identities. The >>>>>>>>> reader needs to be aware that some of these rules are >>>>>>>>> cumulative and can interact in important ways that are >>>>>>>>> illustrated later in this document. >>>>>>>> >>>>>>>> LGTM. >>>>>>> >>>>>>> WFM >>>>>>> >>>>>>> In fact, as I was re-reading RFC 5922, it occurred to me to >>>>>>> wonder if people need guidance one way or another on the idea >>>>>>> of "multi-purpose" certs that might have any number of >>>>>>> subjectAltName entries for different purposes. I'm talking >>>>>>> about virtual domain hosting, or multi-protocol hosts. I >>>>>>> assume in the latter case, you would expect a host to use >>>>>>> different certs for different protocols. In the first case, >>>>>>> is their any guidance to give. I can't remember, do you >>>>>>> mention the TLS server_name extension? >>>>>>> >>>>>>> (I don't mean to suggest any real action here--just thinking >>>>>>> out loud about something that would have been much better to >>>>>>> bring up well before IETF LC. :-) ) >>>>>> >>>>>> Those scenarios are important, but IMHO how the server >>>>>> determines which certificate to present (e.g., based on the SNI >>>>>> or something else, such as the 'to' address on an XMPP stream >>>>>> header) is something that an application protocol specification >>>>>> needs to define. >>>>> >>>>> Agreed. Does this draft need to say that, or do we just take it >>>>> as given? >>>> >>>> I think it's appropriate to add a few words about that. I >>>> suggest... >>>> >>>> 1.1 >>>> >>>> ... When a client connects to an application service using >>>> Transport Layer Security [TLS] or Datagram Transport Layer Security >>>> [DTLS], it references some notion of the server's identity while >>>> attempting to establish a secure connection (e.g., "the website at >>>> example.com") and typically specifies at least the DNS domain name >>>> with which it is trying to communicate (e.g., using a Server Name >>>> Indication during TLS negotiation as described in [TLS-EXT]). >>>> >>>> 1.5 >>>> >>>> presented identifier: An identifier that is presented by a server >>>> to a client within a PKIX certificate when the client attempts to >>>> establish a secure connection with the server; the certificate can >>>> include one or more presented identifiers of different types, and >>>> the certificate presented is typically based on a DNS domain name >>>> specified by the client when initiating communication (e.g., using >>>> a Server Name Indication during TLS negotiation as described in >>>> [TLS-EXT]). >>>> >>> >>> Do you think server_name extension use is actually common enough to >>> call typical? I'm not saying it's not--I don't really know one way or= >>> another. Otherwise, WFM. >=20 > I don't think the TLS server_name extension (aka SNI) is in common > enough use yet to call it "typical". There's a certain > still-widely-deployed version of a certain desktop OS that doesn't > support it, unfortunately. I had changed it to: if the server hosts more than one domain then the certificate it presents might be based on a DNS domain name specified by the client when initiating communication (e.g., using a Server Name Indication during TLS negotiation as described in [TLS-EXT]). That seems suitably vague about how common SNI is. But per your message I think this might belong in a different place. >> We could say "and if the server hosts more than one domain then the >> certificate presented is typically based..." >=20 > Upon re-reading what we presently have in -11 for [S1.1], I don't think= > we need to introduce in that intro paragraph the notion of > disambiguating names in a multi-domain situation. I'd leave that para > as-is. Yes, I'd already removed any mention of SNI from Section 1.1. > in terms of the defn for "presented identifier" in [S1.5], I'd update i= t > like so (I don't think mentioning SNI is reasonable in that defn proper= ).. >=20 > presented identifier: An identifier that is presented by a server > to a client within a PKIX certificate when the client attempts to > establish a secure connection with the server; the certificate can > include one or more presented identifiers of different types, and > if the server hosts more than one domain then the certificate might > present distinct identifiers for each domain. WFM. > I'm wondering if we ought to add an "implementation note" at the end of= > [S3.1] where we mention why one might have a cert with multiple > presented identifiers or a client may employ SNI. >=20 >=20 > Implementation Note: A given application service may be addressed by > multiple domain names for a variety of reasons. In the default [TLS] > handshake exchange, > there is no indication by the client as to the domain name the client > trying to connect to, and the TLS server returns only one certificate > for itself. Thus absent an extension to [TLS], a typical workaround use= d > to facilitate mapping an application service to multiple domain names i= s > to embed the said domain names into the returned application service > certificate. Another approach, more recent and formally specified, is > for the client to use the TLS "Server Name Indication" extension, when > sending the client_hello message, stipulating the domain name the clien= t > used to connect with the application service. The application service > can then return the appropriate certificate in its Certificate message.= > This latter certificate could thus contain a single domain name. >=20 > of course, the FDA notes that the above will require generous > wordsmithing before use. Wordsmithed as follows: ## 5.4. Multiple Identifiers A given application service might be addressed by multiple DNS domain names for a variety of reasons, and a given deployment might service multiple domains (e.g., in so-called "virtual hosting" environments). In the default TLS handshake exchange, the client is not able to indicate the DNS domain name with which it wants to communicate, and the TLS server returns only one certificate for itself. Absent an extension to TLS, a typical workaround used to facilitate mapping an application service to multiple DNS domain names is to embed all of the domain names into a single certificate. A more recent approach, formally specified in [TLS-EXT], is for the client to use the TLS "Server Name Indication" (SNI) extension when sending the client_hello message, stipulating the DNS domain name it desires or expects of the service. The service can then return the appropriate certificate in its Certificate message, and that certificate can represent a single DNS domain name. To accommodate the workaround that was needed before the development of the SNI extension, this specification allows multiple DNS-IDs, SRV-IDs, or URI-IDs in a certificate; however, it explicitly discourages multiple CN-IDs. Although it would be preferable to forbid multiple CN-IDs entirely, there are several reasons at this time why this specification states that they SHOULD NOT (instead of MUST NOT) be included: o At least one significant technology community of interest explicitly allows multiple CN-IDs [EV-CERTS]. o At least one significant certification authority is known to issue certificates containing multiple CN-IDs. o Many service providers often deem inclusion of multiple CN-IDs necessary in virtual hosting environments because at least one widely-deployed operating system does not yet support the SNI extension [TLS-EXT]. It is hoped that the recommendation regarding multiple CN-IDs can be further tightened in the future. ### --------------ms030507050802060003090109 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/ jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q 7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo 98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR 6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV 0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD 0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri 2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6 wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1 nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2 gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1 My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo 6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3 GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6 2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4 TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0 ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+ 39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c 6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2 0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0 H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0 dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTIw ODIzNTUzMFowIwYJKoZIhvcNAQkEMRYEFHwP31wZMb7qer8gcbLx8YEj51HnMF8GCSqGSIb3 DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG 9w0BAQEFAASCAQAxpyG6J1Bbji8fv3qO1TpGCwq3UmTQqx4WEpLF9pvDWTGbCS0VPoEJRIOW c1uDJjZqseXATSQTqWjeEhU7VXWBtYTV7r9OCysH6nmflXxi25croNIKiOLx+21IAlladZ6e j6XFcRQXDUSKvz+fVkYVo643zdDRKYx5lkvvasQjhZvsR0u3w98Ltym0D0IsuuGUs9d1gW4K q6Jugb2Wa9ByRkabcddKtUHKR+r93+15RZ/+UWPDkLHZhyaRc2C2VOxkj+a7hUoFY3OymgFG ApuPovqSCTU78USuXk6TazpPZyqKUf2/n5sG1LQQ085NSRmVgL6Gep9xaXIBhLupcpLBAAAA AAAA --------------ms030507050802060003090109-- From ben@estacado.net Thu Dec 9 06:51: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 8BC0B28C128; Thu, 9 Dec 2010 06:51:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.184 X-Spam-Level: X-Spam-Status: No, score=-1.184 tagged_above=-999 required=5 tests=[AWL=-0.885, BAYES_00=-2.599, MANGLED_LIST=2.3] 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 vE+KxNFb93d6; Thu, 9 Dec 2010 06:51:35 -0800 (PST) Received: from estacado.net (estacado-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:266::2]) by core3.amsl.com (Postfix) with ESMTP id 25BE228C138; Thu, 9 Dec 2010 06:51:25 -0800 (PST) Received: from [10.0.1.12] (cpe-76-183-178-106.tx.res.rr.com [76.183.178.106]) (authenticated bits=0) by estacado.net (8.14.3/8.14.2) with ESMTP id oB9Eqh64000477 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 9 Dec 2010 08:52:53 -0600 (CST) (envelope-from ben@estacado.net) References: <4D000C34.5070008@KingsMountain.com> <4D001AF2.7010000@stpeter.im> In-Reply-To: <4D001AF2.7010000@stpeter.im> Mime-Version: 1.0 (iPad Mail 8C148) Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPad Mail (8C148) From: Ben Campbell Date: Thu, 9 Dec 2010 08:52:41 -0600 To: Peter Saint-Andre Cc: "draft-saintandre-tls-server-id-check.all@tools.ietf.org" , General Area Review Team , "certid@ietf.org" , =JeffH Subject: Re: [certid] [Gen-art] Gen-ART LC Review of draft-saintandre-tls-server-id-check-11 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, 09 Dec 2010 14:51:36 -0000 Still WFM. On Dec 8, 2010, at 5:55 PM, Peter Saint-Andre wrote: > And the wordsmithing continues... > > On 12/8/10 3:52 PM, =JeffH wrote: >> see way below... >> >> PeterSA wrote on Wed, 08 Dec 2010 07:54:52 -0700 (06:54 PST) >>> >>> On 12/8/10 7:37 AM, Ben Campbell wrote: >>>> >>>> >>>> On Dec 8, 2010, at 7:10 AM, Peter Saint-Andre >>>> wrote: >>>> >>>>> On 12/7/10 10:45 PM, Ben Campbell wrote: >>>>>> >>>>>> On Dec 7, 2010, at 11:12 PM, Peter Saint-Andre wrote: >>>>>> >>>>>>> On 12/7/10 6:35 PM, Ben Campbell wrote: >>>>>>>> >>>>>>>> On Dec 6, 2010, at 7:00 PM, =JeffH wrote: >>>>>>>> >>>>>>>>> Peter Saint-Andre replied.. >>>>>>>>>> >>>>>>>>>> On 12/3/10 2:24 PM, "Ben Campbell" >>>>>>>>>> wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>>>>>> -- 3.1, 1st paragraph: >>>>>>>>>>> >>>>>>>>>>> It's probably worth emphasizing that the rules are >>>>>>>>>>> often cumulative. I think someone thinking about these >>>>>>>>>>> for the first time might not grasp that until they see >>>>>>>>>>> examples later in the doc. >>>>>>>>>> >>>>>>>>>> I've added the second sentence to this paragraph: >>>>>>>>>> >>>>>>>>>> When a certification authority issues a certificate based >>>>>>>>>> on the fully-qualified DNS domain name at which the >>>>>>>>>> application service provider will provide the relevant >>>>>>>>>> application, the following rules apply to the >>>>>>>>>> representation of application service identities. The >>>>>>>>>> reader needs to be aware that some of these rules are >>>>>>>>>> cumulative and can interact in important ways that are >>>>>>>>>> illustrated later in this document. >>>>>>>>> >>>>>>>>> LGTM. >>>>>>>> >>>>>>>> WFM >>>>>>>> >>>>>>>> In fact, as I was re-reading RFC 5922, it occurred to me to >>>>>>>> wonder if people need guidance one way or another on the idea >>>>>>>> of "multi-purpose" certs that might have any number of >>>>>>>> subjectAltName entries for different purposes. I'm talking >>>>>>>> about virtual domain hosting, or multi-protocol hosts. I >>>>>>>> assume in the latter case, you would expect a host to use >>>>>>>> different certs for different protocols. In the first case, >>>>>>>> is their any guidance to give. I can't remember, do you >>>>>>>> mention the TLS server_name extension? >>>>>>>> >>>>>>>> (I don't mean to suggest any real action here--just thinking >>>>>>>> out loud about something that would have been much better to >>>>>>>> bring up well before IETF LC. :-) ) >>>>>>> >>>>>>> Those scenarios are important, but IMHO how the server >>>>>>> determines which certificate to present (e.g., based on the SNI >>>>>>> or something else, such as the 'to' address on an XMPP stream >>>>>>> header) is something that an application protocol specification >>>>>>> needs to define. >>>>>> >>>>>> Agreed. Does this draft need to say that, or do we just take it >>>>>> as given? >>>>> >>>>> I think it's appropriate to add a few words about that. I >>>>> suggest... >>>>> >>>>> 1.1 >>>>> >>>>> ... When a client connects to an application service using >>>>> Transport Layer Security [TLS] or Datagram Transport Layer Security >>>>> [DTLS], it references some notion of the server's identity while >>>>> attempting to establish a secure connection (e.g., "the website at >>>>> example.com") and typically specifies at least the DNS domain name >>>>> with which it is trying to communicate (e.g., using a Server Name >>>>> Indication during TLS negotiation as described in [TLS-EXT]). >>>>> >>>>> 1.5 >>>>> >>>>> presented identifier: An identifier that is presented by a server >>>>> to a client within a PKIX certificate when the client attempts to >>>>> establish a secure connection with the server; the certificate can >>>>> include one or more presented identifiers of different types, and >>>>> the certificate presented is typically based on a DNS domain name >>>>> specified by the client when initiating communication (e.g., using >>>>> a Server Name Indication during TLS negotiation as described in >>>>> [TLS-EXT]). >>>>> >>>> >>>> Do you think server_name extension use is actually common enough to >>>> call typical? I'm not saying it's not--I don't really know one way or >>>> another. Otherwise, WFM. >> >> I don't think the TLS server_name extension (aka SNI) is in common >> enough use yet to call it "typical". There's a certain >> still-widely-deployed version of a certain desktop OS that doesn't >> support it, unfortunately. > > I had changed it to: > > if the server hosts more than one domain then the certificate it > presents might be based on a DNS domain name specified by the > client when initiating communication (e.g., using a Server Name > Indication during TLS negotiation as described in [TLS-EXT]). > > That seems suitably vague about how common SNI is. But per your message > I think this might belong in a different place. > >>> We could say "and if the server hosts more than one domain then the >>> certificate presented is typically based..." >> >> Upon re-reading what we presently have in -11 for [S1.1], I don't think >> we need to introduce in that intro paragraph the notion of >> disambiguating names in a multi-domain situation. I'd leave that para >> as-is. > > Yes, I'd already removed any mention of SNI from Section 1.1. > >> in terms of the defn for "presented identifier" in [S1.5], I'd update it >> like so (I don't think mentioning SNI is reasonable in that defn proper).. >> >> presented identifier: An identifier that is presented by a server >> to a client within a PKIX certificate when the client attempts to >> establish a secure connection with the server; the certificate can >> include one or more presented identifiers of different types, and >> if the server hosts more than one domain then the certificate might >> present distinct identifiers for each domain. > > WFM. > >> I'm wondering if we ought to add an "implementation note" at the end of >> [S3.1] where we mention why one might have a cert with multiple >> presented identifiers or a client may employ SNI. >> >> >> Implementation Note: A given application service may be addressed by >> multiple domain names for a variety of reasons. In the default [TLS] >> handshake exchange, >> there is no indication by the client as to the domain name the client >> trying to connect to, and the TLS server returns only one certificate >> for itself. Thus absent an extension to [TLS], a typical workaround used >> to facilitate mapping an application service to multiple domain names is >> to embed the said domain names into the returned application service >> certificate. Another approach, more recent and formally specified, is >> for the client to use the TLS "Server Name Indication" extension, when >> sending the client_hello message, stipulating the domain name the client >> used to connect with the application service. The application service >> can then return the appropriate certificate in its Certificate message. >> This latter certificate could thus contain a single domain name. >> >> of course, the FDA notes that the above will require generous >> wordsmithing before use. > > Wordsmithed as follows: > > ## > > 5.4. Multiple Identifiers > > A given application service might be addressed by multiple DNS domain > names for a variety of reasons, and a given deployment might service > multiple domains (e.g., in so-called "virtual hosting" environments). > In the default TLS handshake exchange, the client is not able to > indicate the DNS domain name with which it wants to communicate, and > the TLS server returns only one certificate for itself. Absent an > extension to TLS, a typical workaround used to facilitate mapping an > application service to multiple DNS domain names is to embed all of > the domain names into a single certificate. > > A more recent approach, formally specified in [TLS-EXT], is for the > client to use the TLS "Server Name Indication" (SNI) extension when > sending the client_hello message, stipulating the DNS domain name it > desires or expects of the service. The service can then return the > appropriate certificate in its Certificate message, and that > certificate can represent a single DNS domain name. > > To accommodate the workaround that was needed before the development > of the SNI extension, this specification allows multiple DNS-IDs, > SRV-IDs, or URI-IDs in a certificate; however, it explicitly > discourages multiple CN-IDs. Although it would be preferable to > forbid multiple CN-IDs entirely, there are several reasons at this > time why this specification states that they SHOULD NOT (instead of > MUST NOT) be included: > > o At least one significant technology community of interest > explicitly allows multiple CN-IDs [EV-CERTS]. > > o At least one significant certification authority is known to issue > certificates containing multiple CN-IDs. > > o Many service providers often deem inclusion of multiple CN-IDs > necessary in virtual hosting environments because at least one > widely-deployed operating system does not yet support the SNI > extension [TLS-EXT]. > > It is hoped that the recommendation regarding multiple CN-IDs can be > further tightened in the future. > > ### > > > > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art From stpeter@stpeter.im Thu Dec 9 07:00: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 2AB7A28C0F3; Thu, 9 Dec 2010 07:00:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.299 X-Spam-Level: X-Spam-Status: No, score=-100.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MANGLED_LIST=2.3, 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 tuUwyQ2+7lBW; Thu, 9 Dec 2010 07:00:43 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id ED70028C0EA; Thu, 9 Dec 2010 07:00:39 -0800 (PST) Received: from squire.local (ip-216-17-182-51.rev.frii.com [216.17.182.51]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 13B1F400F6; Thu, 9 Dec 2010 08:14:05 -0700 (MST) Message-ID: <4D00EF6D.9090503@stpeter.im> Date: Thu, 09 Dec 2010 08:02:05 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: Ben Campbell References: <4D000C34.5070008@KingsMountain.com> <4D001AF2.7010000@stpeter.im> In-Reply-To: X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090003020000080002050208" Cc: "draft-saintandre-tls-server-id-check.all@tools.ietf.org" , General Area Review Team , "certid@ietf.org" , =JeffH Subject: Re: [certid] [Gen-art] Gen-ART LC Review of draft-saintandre-tls-server-id-check-11 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, 09 Dec 2010 15:00:45 -0000 This is a cryptographically signed message in MIME format. --------------ms090003020000080002050208 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks, Ben. I think we're close to declaring victory. :) Jeff and I will work to push out version -12 in the next 48 hours. On 12/9/10 7:52 AM, Ben Campbell wrote: > Still WFM. >=20 > On Dec 8, 2010, at 5:55 PM, Peter Saint-Andre wrot= e: >=20 >> And the wordsmithing continues... >> >> On 12/8/10 3:52 PM, =3DJeffH wrote: >>> see way below... >>> >>> PeterSA wrote on Wed, 08 Dec 2010 07:54:52 -0700 (06:54 PST) >>>> >>>> On 12/8/10 7:37 AM, Ben Campbell wrote: >>>>> >>>>> >>>>> On Dec 8, 2010, at 7:10 AM, Peter Saint-Andre >>>>> wrote: >>>>> >>>>>> On 12/7/10 10:45 PM, Ben Campbell wrote: >>>>>>> >>>>>>> On Dec 7, 2010, at 11:12 PM, Peter Saint-Andre wrote: >>>>>>> >>>>>>>> On 12/7/10 6:35 PM, Ben Campbell wrote: >>>>>>>>> >>>>>>>>> On Dec 6, 2010, at 7:00 PM, =3DJeffH wrote: >>>>>>>>> >>>>>>>>>> Peter Saint-Andre replied.. >>>>>>>>>>> >>>>>>>>>>> On 12/3/10 2:24 PM, "Ben Campbell" >>>>>>>>>>> wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>>> -- 3.1, 1st paragraph: >>>>>>>>>>>> >>>>>>>>>>>> It's probably worth emphasizing that the rules are >>>>>>>>>>>> often cumulative. I think someone thinking about these >>>>>>>>>>>> for the first time might not grasp that until they see >>>>>>>>>>>> examples later in the doc. >>>>>>>>>>> >>>>>>>>>>> I've added the second sentence to this paragraph: >>>>>>>>>>> >>>>>>>>>>> When a certification authority issues a certificate based >>>>>>>>>>> on the fully-qualified DNS domain name at which the >>>>>>>>>>> application service provider will provide the relevant >>>>>>>>>>> application, the following rules apply to the >>>>>>>>>>> representation of application service identities. The >>>>>>>>>>> reader needs to be aware that some of these rules are >>>>>>>>>>> cumulative and can interact in important ways that are >>>>>>>>>>> illustrated later in this document. >>>>>>>>>> >>>>>>>>>> LGTM. >>>>>>>>> >>>>>>>>> WFM >>>>>>>>> >>>>>>>>> In fact, as I was re-reading RFC 5922, it occurred to me to >>>>>>>>> wonder if people need guidance one way or another on the idea >>>>>>>>> of "multi-purpose" certs that might have any number of >>>>>>>>> subjectAltName entries for different purposes. I'm talking >>>>>>>>> about virtual domain hosting, or multi-protocol hosts. I >>>>>>>>> assume in the latter case, you would expect a host to use >>>>>>>>> different certs for different protocols. In the first case, >>>>>>>>> is their any guidance to give. I can't remember, do you >>>>>>>>> mention the TLS server_name extension? >>>>>>>>> >>>>>>>>> (I don't mean to suggest any real action here--just thinking >>>>>>>>> out loud about something that would have been much better to >>>>>>>>> bring up well before IETF LC. :-) ) >>>>>>>> >>>>>>>> Those scenarios are important, but IMHO how the server >>>>>>>> determines which certificate to present (e.g., based on the SNI >>>>>>>> or something else, such as the 'to' address on an XMPP stream >>>>>>>> header) is something that an application protocol specification >>>>>>>> needs to define. >>>>>>> >>>>>>> Agreed. Does this draft need to say that, or do we just take it >>>>>>> as given? >>>>>> >>>>>> I think it's appropriate to add a few words about that. I >>>>>> suggest... >>>>>> >>>>>> 1.1 >>>>>> >>>>>> ... When a client connects to an application service using >>>>>> Transport Layer Security [TLS] or Datagram Transport Layer Securit= y >>>>>> [DTLS], it references some notion of the server's identity while >>>>>> attempting to establish a secure connection (e.g., "the website at= >>>>>> example.com") and typically specifies at least the DNS domain name= >>>>>> with which it is trying to communicate (e.g., using a Server Name >>>>>> Indication during TLS negotiation as described in [TLS-EXT]). >>>>>> >>>>>> 1.5 >>>>>> >>>>>> presented identifier: An identifier that is presented by a server= >>>>>> to a client within a PKIX certificate when the client attempts to >>>>>> establish a secure connection with the server; the certificate can= >>>>>> include one or more presented identifiers of different types, and >>>>>> the certificate presented is typically based on a DNS domain name >>>>>> specified by the client when initiating communication (e.g., using= >>>>>> a Server Name Indication during TLS negotiation as described in >>>>>> [TLS-EXT]). >>>>>> >>>>> >>>>> Do you think server_name extension use is actually common enough to= >>>>> call typical? I'm not saying it's not--I don't really know one way = or >>>>> another. Otherwise, WFM. >>> >>> I don't think the TLS server_name extension (aka SNI) is in common >>> enough use yet to call it "typical". There's a certain >>> still-widely-deployed version of a certain desktop OS that doesn't >>> support it, unfortunately. >> >> I had changed it to: >> >> if the server hosts more than one domain then the certificate it >> presents might be based on a DNS domain name specified by the >> client when initiating communication (e.g., using a Server Name >> Indication during TLS negotiation as described in [TLS-EXT]). >> >> That seems suitably vague about how common SNI is. But per your messag= e >> I think this might belong in a different place. >> >>>> We could say "and if the server hosts more than one domain then the >>>> certificate presented is typically based..." >>> >>> Upon re-reading what we presently have in -11 for [S1.1], I don't thi= nk >>> we need to introduce in that intro paragraph the notion of >>> disambiguating names in a multi-domain situation. I'd leave that para= >>> as-is. >> >> Yes, I'd already removed any mention of SNI from Section 1.1. >> >>> in terms of the defn for "presented identifier" in [S1.5], I'd update= it >>> like so (I don't think mentioning SNI is reasonable in that defn prop= er).. >>> >>> presented identifier: An identifier that is presented by a server >>> to a client within a PKIX certificate when the client attempts to >>> establish a secure connection with the server; the certificate can >>> include one or more presented identifiers of different types, and >>> if the server hosts more than one domain then the certificate might >>> present distinct identifiers for each domain. >> >> WFM. >> >>> I'm wondering if we ought to add an "implementation note" at the end = of >>> [S3.1] where we mention why one might have a cert with multiple >>> presented identifiers or a client may employ SNI. >>> >>> >>> Implementation Note: A given application service may be addressed by= >>> multiple domain names for a variety of reasons. In the default [TLS] >>> handshake exchange, >>> there is no indication by the client as to the domain name the client= >>> trying to connect to, and the TLS server returns only one certificate= >>> for itself. Thus absent an extension to [TLS], a typical workaround u= sed >>> to facilitate mapping an application service to multiple domain names= is >>> to embed the said domain names into the returned application service >>> certificate. Another approach, more recent and formally specified, is= >>> for the client to use the TLS "Server Name Indication" extension, whe= n >>> sending the client_hello message, stipulating the domain name the cli= ent >>> used to connect with the application service. The application service= >>> can then return the appropriate certificate in its Certificate messag= e. >>> This latter certificate could thus contain a single domain name. >>> >>> of course, the FDA notes that the above will require generous >>> wordsmithing before use. >> >> Wordsmithed as follows: >> >> ## >> >> 5.4. Multiple Identifiers >> >> A given application service might be addressed by multiple DNS domai= n >> names for a variety of reasons, and a given deployment might service= >> multiple domains (e.g., in so-called "virtual hosting" environments)= =2E >> In the default TLS handshake exchange, the client is not able to >> indicate the DNS domain name with which it wants to communicate, and= >> the TLS server returns only one certificate for itself. Absent an >> extension to TLS, a typical workaround used to facilitate mapping an= >> application service to multiple DNS domain names is to embed all of >> the domain names into a single certificate. >> >> A more recent approach, formally specified in [TLS-EXT], is for the >> client to use the TLS "Server Name Indication" (SNI) extension when >> sending the client_hello message, stipulating the DNS domain name it= >> desires or expects of the service. The service can then return the >> appropriate certificate in its Certificate message, and that >> certificate can represent a single DNS domain name. >> >> To accommodate the workaround that was needed before the development= >> of the SNI extension, this specification allows multiple DNS-IDs, >> SRV-IDs, or URI-IDs in a certificate; however, it explicitly >> discourages multiple CN-IDs. Although it would be preferable to >> forbid multiple CN-IDs entirely, there are several reasons at this >> time why this specification states that they SHOULD NOT (instead of >> MUST NOT) be included: >> >> o At least one significant technology community of interest >> explicitly allows multiple CN-IDs [EV-CERTS]. >> >> o At least one significant certification authority is known to issu= e >> certificates containing multiple CN-IDs. >> >> o Many service providers often deem inclusion of multiple CN-IDs >> necessary in virtual hosting environments because at least one >> widely-deployed operating system does not yet support the SNI >> extension [TLS-EXT]. >> >> It is hoped that the recommendation regarding multiple CN-IDs can be= >> further tightened in the future. >> >> ### >> >> >> >> _______________________________________________ >> Gen-art mailing list >> Gen-art@ietf.org >> https://www.ietf.org/mailman/listinfo/gen-art --------------ms090003020000080002050208 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/ jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q 7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo 98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR 6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV 0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD 0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri 2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6 wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1 nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2 gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1 My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo 6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3 GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6 2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4 TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0 ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+ 39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c 6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2 0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0 H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0 dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTIw OTE1MDIwNVowIwYJKoZIhvcNAQkEMRYEFOf84M0MoAJrwgojgfARrEYL0JfJMF8GCSqGSIb3 DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG 9w0BAQEFAASCAQBTVqP1m9N1Eb/eRkn1P1lxghu/PO9u0qV6EXYUR27TiFvlB6s7nCpNkvNQ BqezNyoP50QdwPLlM5Xnl3HcyNZYHWWemrk0TlEVbOQ9AIwpO8bJRGVhFd+Nz/hWCe+hUJqx qj/CcCKsgHhWOz5XYskIVbJ799Kg+M5OPJ8we/N8O9/zxbNm4JPc0IzhOR9mrbLZm6EaZigk AUl5sK0b7TdRjYRduZATd7E1YBBjtfEWWrGrpKr5y20Jk4p2+cFj6ZRsTZJ68+qdsus+WDmJ 8I0HFV2IvPJreSrtTvjMOmIgJKGSvWrO/9VbMKQ2fIBhh8wg4Q431zCIUAQz0+Q2l7JEAAAA AAAA --------------ms090003020000080002050208-- From Jeff.Hodges@KingsMountain.com Thu Dec 9 09:30:54 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 E76F428C128 for ; Thu, 9 Dec 2010 09:30:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.208 X-Spam-Level: X-Spam-Status: No, score=-102.208 tagged_above=-999 required=5 tests=[AWL=0.391, BAYES_00=-2.599, 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 t2fxlbyPVMR4 for ; Thu, 9 Dec 2010 09:30:50 -0800 (PST) Received: from oproxy1-pub.bluehost.com (oproxy1-pub.bluehost.com [66.147.249.253]) by core3.amsl.com (Postfix) with SMTP id CDB7628C146 for ; Thu, 9 Dec 2010 09:30:47 -0800 (PST) Received: (qmail 2871 invoked by uid 0); 9 Dec 2010 17:32:07 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy1.bluehost.com.bluehost.com with SMTP; 9 Dec 2010 17:32:07 -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:CC:Subject:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=MGX+IcPb8hED5+JV1yz8qQS/pkCNKGIH0Muld2U/Su4p9YFRrRrJE/Qg6dCsC5QqTqeTsoKxfPtI4cKv7GQvKrGP1OpswDdWcYXefvlWAobsFwENbSnakuquAAXPiNUg; 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 1PQkLf-0005hI-2s; Thu, 09 Dec 2010 10:32:07 -0700 Message-ID: <4D011294.7030200@KingsMountain.com> Date: Thu, 09 Dec 2010 09:32:04 -0800 From: =JeffH User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: Peter Saint-Andre 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} Cc: draft-saintandre-tls-server-id-check.all@tools.ietf.org, General Area Review Team , certid@ietf.org Subject: Re: [certid] Gen-ART LC Review of draft-saintandre-tls-server-id-check-11 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, 09 Dec 2010 17:30:55 -0000 PeterSA replied.. > > And the wordsmithing continues... > > On 12/8/10 3:52 PM, =JeffH wrote: >> see way below... >> >> PeterSA wrote on Wed, 08 Dec 2010 07:54:52 -0700 (06:54 PST) >>> >>> On 12/8/10 7:37 AM, Ben Campbell wrote: >>>> >>>> >>>> On Dec 8, 2010, at 7:10 AM, Peter Saint-Andre >>>> wrote: >>>> >>>>> On 12/7/10 10:45 PM, Ben Campbell wrote: >>>>>> >>>>>> On Dec 7, 2010, at 11:12 PM, Peter Saint-Andre wrote: >>>>>> >>>>>>> On 12/7/10 6:35 PM, Ben Campbell wrote: >>>>>>>> >>>>>>>> On Dec 6, 2010, at 7:00 PM, =JeffH wrote: >>>>>>>> >>>>>>>>> Peter Saint-Andre replied.. >>>>>>>>>> >>>>>>>>>> On 12/3/10 2:24 PM, "Ben Campbell" >>>>>>>>>> wrote: >>>>>>> >>>> Do you think server_name extension use is actually common enough to >>>> call typical? I'm not saying it's not--I don't really know one way or >>>> another. Otherwise, WFM. >> >> I don't think the TLS server_name extension (aka SNI) is in common >> enough use yet to call it "typical". There's a certain >> still-widely-deployed version of a certain desktop OS that doesn't >> support it, unfortunately. > > I had changed it to: > > if the server hosts more than one domain then the certificate it > presents might be based on a DNS domain name specified by the > client when initiating communication (e.g., using a Server Name > Indication during TLS negotiation as described in [TLS-EXT]). > > That seems suitably vague about how common SNI is. But per your message > I think this might belong in a different place. > >>> We could say "and if the server hosts more than one domain then the >>> certificate presented is typically based..." >> >> Upon re-reading what we presently have in -11 for [S1.1], I don't think >> we need to introduce in that intro paragraph the notion of >> disambiguating names in a multi-domain situation. I'd leave that para >> as-is. > > Yes, I'd already removed any mention of SNI from Section 1.1. thx. > >> in terms of the defn for "presented identifier" in [S1.5], I'd update it >> like so (I don't think mentioning SNI is reasonable in that defn proper).. >> >> presented identifier: An identifier that is presented by a server >> to a client within a PKIX certificate when the client attempts to >> establish a secure connection with the server; the certificate can >> include one or more presented identifiers of different types, and >> if the server hosts more than one domain then the certificate might >> present distinct identifiers for each domain. > > WFM. super. > >> I'm wondering if we ought to add an "implementation note" at the end of >> [S3.1] where we mention why one might have a cert with multiple >> presented identifiers or a client may employ SNI. >> >> >> Implementation Note: >> >> of course, the FDA notes that the above will require generous >> wordsmithing before use. > > Wordsmithed as follows: > > ## > > 5.4. Multiple Identifiers > > A given application service might be addressed by multiple DNS domain > names for a variety of reasons, and a given deployment might service > multiple domains (e.g., in so-called "virtual hosting" environments). > In the default TLS handshake exchange, the client is not able to > indicate the DNS domain name with which it wants to communicate, and > the TLS server returns only one certificate for itself. Absent an > extension to TLS, a typical workaround used to facilitate mapping an > application service to multiple DNS domain names is to embed all of > the domain names into a single certificate. > > A more recent approach, formally specified in [TLS-EXT], is for the > client to use the TLS "Server Name Indication" (SNI) extension when > sending the client_hello message, stipulating the DNS domain name it > desires or expects of the service. The service can then return the > appropriate certificate in its Certificate message, and that > certificate can represent a single DNS domain name. > > To accommodate the workaround that was needed before the development > of the SNI extension, this specification allows multiple DNS-IDs, > SRV-IDs, or URI-IDs in a certificate; however, it explicitly > discourages multiple CN-IDs. Although it would be preferable to > forbid multiple CN-IDs entirely, there are several reasons at this > time why this specification states that they SHOULD NOT (instead of > MUST NOT) be included: > > o At least one significant technology community of interest > explicitly allows multiple CN-IDs [EV-CERTS]. > > o At least one significant certification authority is known to issue > certificates containing multiple CN-IDs. > > o Many service providers often deem inclusion of multiple CN-IDs > necessary in virtual hosting environments because at least one > widely-deployed operating system does not yet support the SNI > extension [TLS-EXT]. > > It is hoped that the recommendation regarding multiple CN-IDs can be > further tightened in the future. > > ### excellent smithing there, thanks. =JeffH From stpeter@stpeter.im Mon Dec 13 11:48:14 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 290D828C100 for ; Mon, 13 Dec 2010 11:48:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.762 X-Spam-Level: X-Spam-Status: No, score=-102.762 tagged_above=-999 required=5 tests=[AWL=-0.163, BAYES_00=-2.599, 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 kZ25XjJucucv for ; Mon, 13 Dec 2010 11:48:13 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 2216728C0DF for ; Mon, 13 Dec 2010 11:48:13 -0800 (PST) Received: from dhcp-64-101-72-234.cisco.com (dhcp-64-101-72-234.cisco.com [64.101.72.234]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 6043A400F6; Mon, 13 Dec 2010 13:02:10 -0700 (MST) Message-ID: <4D0678DD.7080608@stpeter.im> Date: Mon, 13 Dec 2010 12:49:49 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: IETF cert-based identity X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms050305080005000306020100" Cc: Ben Campbell Subject: [certid] version 12 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, 13 Dec 2010 19:48:14 -0000 This is a cryptographically signed message in MIME format. --------------ms050305080005000306020100 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Jeff and I have published version -12. The changes were driven by the Gen-ART review that Ben Campbell did, some feedback from our sponsoring Area Director, a few list discussions, and several rounds of editorial improvement. http://www.ietf.org/id/draft-saintandre-tls-server-id-check-12.txt The diff from -11 is here: http://tools.ietf.org/rfcdiff?url2=3Ddraft-saintandre-tls-server-id-check= -12.txt Thanks! Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms050305080005000306020100 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/ jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q 7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo 98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR 6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV 0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD 0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri 2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6 wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1 nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2 gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1 My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo 6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3 GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6 2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4 TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0 ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+ 39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c 6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2 0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0 H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0 dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTIx MzE5NDk0OVowIwYJKoZIhvcNAQkEMRYEFK1k++S8TnB5GfGXxGJ+igh/FfNwMF8GCSqGSIb3 DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG 9w0BAQEFAASCAQCJCZjIAihYfpObr8jLaBVNidWy7M4Ws/3Cu3GeLT8wcVShS1uoQsqHbsa8 79OwBIHjcnj+lA7IxVQ6CXapL3EKzfM1EJXXxpmRNLvedzBDGzphc47iKaTPOSnQZIIgtnBk A4t53dHGtMCK47l4gy208AChuBgeAiLVz5fEWc2hop6Q+6pvtlP/FzrCTQncNMfWAFk9DEg9 I0WoL6rg85XmtkrhN0TEhICEh+OXq2KGFSQXO+SOiBdj1R7QHZU6274bfcfCp7eapXWN/xB0 weJGmIGFR126h39LCAdBV1ZTtMfR86ppU3LR4V95o5cjhrYdPKx1MiLo/j8mJXoVjhEJAAAA AAAA --------------ms050305080005000306020100-- From paul.hoffman@vpnc.org Thu Dec 16 06:27:32 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 40D4F28C163 for ; Thu, 16 Dec 2010 06:27:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.046 X-Spam-Level: X-Spam-Status: No, score=-102.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 oQZevaRBxNBa for ; Thu, 16 Dec 2010 06:27:30 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 3E59728C166 for ; Thu, 16 Dec 2010 06:27:30 -0800 (PST) Received: from [10.20.30.150] (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 oBGETD27037573 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 16 Dec 2010 07:29:14 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Thu, 16 Dec 2010 06:29:11 -0800 To: certid@ietf.org From: Cullen Jennings Content-Type: text/plain; charset="us-ascii" Subject: [certid] Review of draft-saintandre-tls-server-id-check-12 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, 16 Dec 2010 14:27:32 -0000 So let me start with I think there is great information in here and I think it should be published as a standards track RFC however I do think there are some issues with the relation with this draft and the realities of what would help improve security in deployment of SIP, HTTP, IMAP, XMPP etc. There are many places where this draft makes choices to improve the security from many current practices. At face value this seems like a good thing but it's not always. The thing reducing the overall security available to users of TLS is not if certs use CN-ID or DNS-ID, it is that it's such a PITA to deploy a TLS server that people choose to not use TLS at all. Everywhere there is a trade off between making things marginally more secure, or making things cheaper and easer to deploy, I think we need to seriously consider the cheaper and easier approach. Yes, some things are just broken even if they are easy and obviously we can't do those. Let me give an example of this. I looked at the cert for the domains for the authors of this draft. www.cisco.com has 3 DNS names even though as fas as I can tell one of these are for something that would typically be used in a ftp URI and the other HTTP URI. This is because it makes it easier and cheaper for them to use TLS yet seems to go against the recommendation of this "BCP". Then I went over the www.paypal.com domain which uses, gasp, a CN-ID. Do we really believe that paypal is seriously compromising their security by using a CN instead of URI-ID? If so, how? I'm pretty sure the paypal guys know how to run a secure web server. With the exception of Microsoft small business server certificates (which are outrageously expensive by the way) it pretty hard to get SRV name certs. In making these recommendations, did the TLS WG consider the relative prices of various types of certificates? Lets say I had a certificate for the domain example.org because I was using it for email and it has a CN because I got it years ago. Now lets say I am going to go deploy a SIP service on example.org. My position is that best way to encourage the use of security on the internet is to just reuse the certificate I have. It cheap, it's easy, it secure enough even if it does make you feel a bit dirty. I think Jeff disagrees w ith me, we argued for years about this topic and my understanding is his position is that it would be better to say that all new deployments MUST not use a CN name because it's less secure. Give the prevalence of CN on the internet today, I think it is fine to tell people how DNS-ID is better but I don't think it's OK to tell them they should not use CN-ID and I definitely don't think it is OK to tell implementors they don't need to implement CN-ID. I encouraged Chris to write this draft long ago and what we had discussed at the time was forming a RFC with one or more boiler plate pieces of text that could be used in creation of the name matching section of new protocols that got developed. I was thinking of something similar to the way we use rfc 5226 for writing IANA consideration section. Instead we have a document that is creating a very complex situations about whats normative. This draft is a BCP level, and it says you have to do everything in PKIX and PKIX takes precedence. That is basically elevating PKIX to a BCP without appropriate process review. Next this draft contradicts the procedures in existing protocols and says that it does not apply to the existing protocols but that it would take precedence over any future updates of existing protocols that use TLS within the scope specified here. I do not believe you have the consensus of the people woking on SIP that the next time some specification is marked as an UPDATE to 3261, that implementations need to implement the procedures in this draft. Furthermore, I think that would be counter productive. I think you should make it clear this guidelines for designers of new protocol and people updating existing protocol and that these protocols could make their own choices but would want to take into account the information in this draft. When I read the sentence, "However, the best current practices described here can be referenced by future specifications, including updates to specifications for existing application protocols if the relevant technology communities agree to do so." I think that is exactly the right solution to the problem. However, that not a BCP, thats a standards track spec. Furthermore, I think this draft is going to have all the normal bugs etc of any other spec that defines algorithms and such it should proceed through the standards track process. If this draft is going to go as a BCP, that text contradicts what a BCP is and needs to come out and the rest of the draft be adjusted appropriately. My preference would be that this draft be standards track. Its writing exactly the same sort of normative algorithm text that we put in all kinds of other thing like SIP, HTTP, and even TLS. They are all standards track. This should be the same. Most RFCs today that use TLS have a page plus or minus that tells an implementer what they need to know about matching names in certs. This draft move that to 30 to 50 pages depending on how you count. Most implementers are just going to ignore this thus worsening the security situation. Think about why is the part implementers need to read 10x longer than existing deceptions - this just seems wrong. Now it's easy to blow off this type concern and say get over it, it's the same number of lines of code they need to write. But the problem is when an implementors goes to start doing this and encounters something that is 50 pages long, they instantly decide this is a big task and down it goes on the priority list of actually happening. The other problem is that even thous it is long, it is still very confusing on how to do things (such at URI). I'll provide more detailed examples of this later in this email. If the document was restructured to have all the normative text in one s hort simple description and the rest moved to an appendix, it would be much easier to get people to take this seriously and easier to review that it was correct. My final big issue is the use of normative language. Lets say there are two procedures A and B and we 100% consensus that B is better than A but we still have to support A for existing deployment reasons. To describe this, the text this draft would use is is MUST do A and SHOULD NOT do B. Now reading 2119 it is pretty clear that SHOULD NOT means you don't implement it unless there are real good reasons to implement it. So on the things were we agree A is preferred to B but you need both for backwards compatibility, this draft needs to say MUST implement A and MUST implement B but deployments are encouraged to use B as we are trying to move away from A. I think the whole document needs a careful read checking for this issue. You can insert the usual rant here about why SHOULD is a awful word in specs 90% of the time it used because implementer thinks it means "ignore rest of sentence". For example, section 5.4 discusses they this spec continues to mandate protocols MUST suppo rt CN yet this draft continually use "SHOULD NOT" when what it really means is MUST implement. This is going to confuse implementors of IETF specification and be ignored by operators. Given the goals of this spec it would be much better if it was clearly defining what IETF required implementers of protocols to do instead of confusing that with how we wish security was deployed. On to the nits. Take an applications like a web server. Is the preferred thing in a cert a DNS-ID or a URI-ID. My reading of the 3.3 is that URI-ID is preferred over DNS-ID yet the examples don't match that. I think point 3 in section 3.1 tries to explain this away but I don't understand that - clearly web browsers use a URI. The rules in section 3.1 don't make sense for a CA. How will the CA know if the cert I want is going to be used for a protocol that uses SRV? In section 3.2, in the imap example, you are saying that if I configure my imap server to mail.example.com and it presents a certificate with a DNS-ID of example.com that this is OK. That does not sound OK to me but I don't know how IMAP works. In the SIP example, the cert should have a SRV and DNS name too. As well as a CN if you actually want it to work in the real world. In section 4.2.1 you have a long discussion on how the information used must come from a way that can't be tampered with over the internet. I generally agree with this but would like to point out that protocols like LOST (see section 18 of rfc5222) specially do the opposite of this and actually match the cert agains the output of NAPTR process not the input to the NAPTR process. The example just seem plain wrong in some cases. Take for example section 4.2.2 where the SIP example has only a URI reference identifiers and no DNS yet the section right before this has said the list MUST include a DNS-ID. This text has been through how many reviews and Last Calls? The problem here is that this draft is too long to review for stuff like this. Even after the IESG is done reviewing it, statistics suggest it will still be littered with bugs like this and implementors will use the examples to guide them. If someone implements what is in the example, it will break in lots of sip deployments. There is a whole algorithm about matching various ID types, but the note about you ignore CN if you have other things is off in "Security Warning" very much out of any flow of the algorithm description then pointed out again in some other section. It's not wrong, but it's a bit weird from an implementer point of view. Many applications do need to deal with IP matching as well as domain names. The way this text is written here makes it harder to figure out how and where to mix that in. I'd rather see it just dealt with than instead of making it out of scope. Obviously it's not common on internet but it is common on private networks and walled gardens where many of the protocols were are talking about are deployed. Many of the "internet of things" people I work with have no intention of using DNS at all. I scoffed at multiple large service providers 10 years ago when they said they were not using DNS with SIP but many still use IPs. This sounds less insane when you consider the major OS don't ship with an asynchronous DNS library. I'm baffled on why checking the service name in a SRV record is a SHOULD not a MUST. Could you add text explain why and when one would not check it. If you were in a really good mood you could do that for all the SHOULDs. Actually, when I read section 4.5 carefully, I think it literally says that when using a URI, checking the domain name is a SHOULD not a MUST. Surely check the domain name matches is not a SHOULD level sort of thing. Section 5.4. I have no idea why it matters that some major OS does not support SNI. Even if that OS did support SNI, many many applications running on that OS and the others would not support SNI. It seems like it is the applications acting as TLS servers and clients that are the important thing, not the OS. How you process URI-ID needs work. I could not figure out how to implement given the text in the draft as is. Even ignoring the special tar pit the SIP guys dug for themselves with tel URL processing, just the normal sip, sips issues seems unclear. This seems like a long list of complaints delivered fairly late but, once again, I really do like much of the information in here and think it should be published as PS - it just would be significantly improved with a bit of a re-factored and clean up. If this had been run through the TLS working group, I would have caught all of this in the WG LC. This is a draft that, as a BCP, profoundly effects many of the protocols I work on including SIP but as far as I can tell has not done much to gather the consensus of the people working on protocol that this draft changes - I don't recall hearing about it until after it went to the IESG so I'm pretty un apologetic about providing these comments during IETF LC. In summary, I like the information in this but I think it still has many small things that need fixing and needs to be changed to get crisp about what implementors need to do and drop the confusing stuff about how we wish operators and CA might use certificates. I also feel strongly that the right way to look at this draft is, as that draft says "practices described here can be referenced by future specifications, including updates to specifications for existing application protocols if the relevant technology communities agree to do so" and that for that reason it has to be standards track not BCP. If it was not being written and pushed by two IESG members, I don't think we would even be discussing if it should be a BCP. _______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf From stpeter@stpeter.im Thu Dec 16 07:20:37 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 B42F43A6887; Thu, 16 Dec 2010 07:20:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.443 X-Spam-Level: X-Spam-Status: No, score=-102.443 tagged_above=-999 required=5 tests=[AWL=0.156, BAYES_00=-2.599, 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 utvSYNI-a3XE; Thu, 16 Dec 2010 07:20:34 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id AF6003A6863; Thu, 16 Dec 2010 07:20:34 -0800 (PST) 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 73B104009B; Thu, 16 Dec 2010 08:34:52 -0700 (MST) Message-ID: <4D0A2EA8.6080709@stpeter.im> Date: Thu, 16 Dec 2010 08:22:16 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Cullen Jennings References: <58FE898B-BD2A-4C6E-B769-256008D8A58B@cisco.com> In-Reply-To: <58FE898B-BD2A-4C6E-B769-256008D8A58B@cisco.com> X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms020200010102060400040507" Cc: IETF cert-based identity , IESG IESG , The IETF Subject: Re: [certid] Review of draft-saintandre-tls-server-id-check-12 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, 16 Dec 2010 15:20:37 -0000 This is a cryptographically signed message in MIME format. --------------ms020200010102060400040507 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks for your comments. My co-author and I will need to confer before replying, and that might take a few days given the length of your review.= Peter On 12/16/10 12:17 AM, Cullen Jennings wrote: >=20 > So let me start with I think there is great information in here and I > think it should be published as a standards track RFC however I do > think there are some issues with the relation with this draft and the > realities of what would help improve security in deployment of SIP, > HTTP, IMAP, XMPP etc. >=20 > There are many places where this draft makes choices to improve the > security from many current practices. At face value this seems like a > good thing but it's not always. The thing reducing the overall > security available to users of TLS is not if certs use CN-ID or > DNS-ID, it is that it's such a PITA to deploy a TLS server that > people choose to not use TLS at all. Everywhere there is a trade off > between making things marginally more secure, or making things > cheaper and easer to deploy, I think we need to seriously consider > the cheaper and easier approach. Yes, some things are just broken > even if they are easy and obviously we can't do those. Let me give an > example of this. I looked at the cert for the domains for the authors > of this draft. www.cisco.com has 3 DNS names even though as fas as I > can tell one of these are for something that would typically be used > in a ftp URI and the other HTTP URI. This is because it makes it > easier and cheaper for them to use TLS yet seems to go against the > recommendation of this "BCP". Then I went over the www.paypal.com > domain which uses, gasp, a CN-ID. Do we really believe that paypal is > seriously compromising their security by using a CN instead of > URI-ID? If so, how? I'm pretty sure the paypal guys know how to run a > secure web server. With the exception of Microsoft small business > server certificates (which are outrageously expensive by the way) it > pretty hard to get SRV name certs. In making these recommendations, > did the TLS WG consider the relative prices of various types of > certificates? Lets say I had a certificate for the domain example.org > because I was using it for email and it has a CN because I got it > years ago. Now lets say I am going to go deploy a SIP service on > example.org. My position is that best way to encourage the use of > security on the internet is to just reuse the certificate I have. It > cheap, it's easy, it secure enough even if it does make you feel a > bit dirty. I think Jeff disagrees w ith me, we argued for years about > this topic and my understanding is his position is that it would be > better to say that all new deployments MUST not use a CN name because > it's less secure. Give the prevalence of CN on the internet today, I > think it is fine to tell people how DNS-ID is better but I don't > think it's OK to tell them they should not use CN-ID and I definitely > don't think it is OK to tell implementors they don't need to > implement CN-ID. >=20 > I encouraged Chris to write this draft long ago and what we had > discussed at the time was forming a RFC with one or more boiler plate > pieces of text that could be used in creation of the name matching > section of new protocols that got developed. I was thinking of > something similar to the way we use rfc 5226 for writing IANA > consideration section. Instead we have a document that is creating a > very complex situations about whats normative. This draft is a BCP > level, and it says you have to do everything in PKIX and PKIX takes > precedence. That is basically elevating PKIX to a BCP without > appropriate process review. Next this draft contradicts the > procedures in existing protocols and says that it does not apply to > the existing protocols but that it would take precedence over any > future updates of existing protocols that use TLS within the scope > specified here. I do not believe you have the consensus of the people > woking on SIP that the next time some specification is marked as an=20 > UPDATE to 3261, that implementations need to implement the procedures > in this draft. Furthermore, I think that would be counter productive. > I think you should make it clear this guidelines for designers of new > protocol and people updating existing protocol and that these > protocols could make their own choices but would want to take into > account the information in this draft. When I read the sentence,=20 > "However, the best current practices described here can be referenced > by future specifications, including updates to specifications for > existing application protocols if the relevant technology communities > agree to do so." I think that is exactly the right solution to the > problem. However, that not a BCP, thats a standards track spec. > Furthermore, I think this draft is going to have all the normal bugs > etc of any other spec that defines algorithms and such it should > proceed through the standards track process. If this draft is going > to go as a BCP, that text contradicts what a BCP is and needs to come > out and the rest of the draft be adjusted appropriately. My > preference would be that this draft be standards track. Its writing > exactly the same sort of normative algorithm text that we put in all > kinds of other thing like SIP, HTTP, and even TLS. They are all > standards track. This should be the same. >=20 > Most RFCs today that use TLS have a page plus or minus that tells an > implementer what they need to know about matching names in certs. > This draft move that to 30 to 50 pages depending on how you count. > Most implementers are just going to ignore this thus worsening the > security situation. Think about why is the part implementers need to > read 10x longer than existing deceptions - this just seems wrong. Now > it's easy to blow off this type concern and say get over it, it's the > same number of lines of code they need to write. But the problem is > when an implementors goes to start doing this and encounters > something that is 50 pages long, they instantly decide this is a big > task and down it goes on the priority list of actually happening. The > other problem is that even thous it is long, it is still very > confusing on how to do things (such at URI). I'll provide more > detailed examples of this later in this email. If the document was > restructured to have all the normative text in one s hort simple > description and the rest moved to an appendix, it would be much > easier to get people to take this seriously and easier to review that > it was correct. >=20 > My final big issue is the use of normative language. Lets say there > are two procedures A and B and we 100% consensus that B is better > than A but we still have to support A for existing deployment > reasons. To describe this, the text this draft would use is is MUST > do A and SHOULD NOT do B. Now reading 2119 it is pretty clear that > SHOULD NOT means you don't implement it unless there are real good > reasons to implement it. So on the things were we agree A is > preferred to B but you need both for backwards compatibility, this > draft needs to say MUST implement A and MUST implement B but > deployments are encouraged to use B as we are trying to move away > from A. I think the whole document needs a careful read checking for > this issue. You can insert the usual rant here about why SHOULD is a > awful word in specs 90% of the time it used because implementer > thinks it means "ignore rest of sentence". For example, section 5.4 > discusses they this spec continues to mandate protocols MUST suppo rt > CN yet this draft continually use "SHOULD NOT" when what it really > means is MUST implement. This is going to confuse implementors of > IETF specification and be ignored by operators. Given the goals of > this spec it would be much better if it was clearly defining what > IETF required implementers of protocols to do instead of confusing > that with how we wish security was deployed. >=20 >=20 > On to the nits. >=20 > Take an applications like a web server. Is the preferred thing in a > cert a DNS-ID or a URI-ID. My reading of the 3.3 is that URI-ID is > preferred over DNS-ID yet the examples don't match that. I think > point 3 in section 3.1 tries to explain this away but I don't > understand that - clearly web browsers use a URI. >=20 > The rules in section 3.1 don't make sense for a CA. How will the CA > know if the cert I want is going to be used for a protocol that uses > SRV? >=20 > In section 3.2, in the imap example, you are saying that if I > configure my imap server to mail.example.com and it presents a > certificate with a DNS-ID of example.com that this is OK. That does > not sound OK to me but I don't know how IMAP works. In the SIP > example, the cert should have a SRV and DNS name too. As well as a CN > if you actually want it to work in the real world. >=20 > In section 4.2.1 you have a long discussion on how the information > used must come from a way that can't be tampered with over the > internet. I generally agree with this but would like to point out > that protocols like LOST (see section 18 of rfc5222) specially do the > opposite of this and actually match the cert agains the output of > NAPTR process not the input to the NAPTR process. >=20 > The example just seem plain wrong in some cases. Take for example > section 4.2.2 where the SIP example has only a URI reference > identifiers and no DNS yet the section right before this has said the > list MUST include a DNS-ID. This text has been through how many > reviews and Last Calls? The problem here is that this draft is too > long to review for stuff like this. Even after the IESG is done > reviewing it, statistics suggest it will still be littered with bugs > like this and implementors will use the examples to guide them. If > someone implements what is in the example, it will break in lots of > sip deployments. >=20 > There is a whole algorithm about matching various ID types, but the > note about you ignore CN if you have other things is off in "Security > Warning" very much out of any flow of the algorithm description then > pointed out again in some other section. It's not wrong, but it's a > bit weird from an implementer point of view. >=20 > Many applications do need to deal with IP matching as well as domain > names. The way this text is written here makes it harder to figure > out how and where to mix that in. I'd rather see it just dealt with > than instead of making it out of scope. Obviously it's not common on > internet but it is common on private networks and walled gardens > where many of the protocols were are talking about are deployed. Many > of the "internet of things" people I work with have no intention of > using DNS at all. I scoffed at multiple large service providers 10 > years ago when they said they were not using DNS with SIP but many > still use IPs. This sounds less insane when you consider the major OS > don't ship with an asynchronous DNS library. >=20 > I'm baffled on why checking the service name in a SRV record is a > SHOULD not a MUST. Could you add text explain why and when one would > not check it. If you were in a really good mood you could do that for > all the SHOULDs. Actually, when I read section 4.5 carefully, I think > it literally says that when using a URI, checking the domain name is > a SHOULD not a MUST. Surely check the domain name matches is not a > SHOULD level sort of thing. >=20 > Section 5.4. I have no idea why it matters that some major OS does > not support SNI. Even if that OS did support SNI, many many > applications running on that OS and the others would not support SNI. > It seems like it is the applications acting as TLS servers and > clients that are the important thing, not the OS. >=20 > How you process URI-ID needs work. I could not figure out how to > implement given the text in the draft as is. Even ignoring the > special tar pit the SIP guys dug for themselves with tel URL > processing, just the normal sip, sips issues seems unclear. >=20 > This seems like a long list of complaints delivered fairly late but, > once again, I really do like much of the information in here and > think it should be published as PS - it just would be significantly > improved with a bit of a re-factored and clean up. If this had been > run through the TLS working group, I would have caught all of this in > the WG LC. This is a draft that, as a BCP, profoundly effects many > of the protocols I work on including SIP but as far as I can tell has > not done much to gather the consensus of the people working on > protocol that this draft changes - I don't recall hearing about it > until after it went to the IESG so I'm pretty un apologetic about > providing these comments during IETF LC. >=20 > In summary, I like the information in this but I think it still has > many small things that need fixing and needs to be changed to get > crisp about what implementors need to do and drop the confusing stuff > about how we wish operators and CA might use certificates. I also > feel strongly that the right way to look at this draft is, as that > draft says "practices described here can be referenced by future > specifications, including updates to specifications for existing > application protocols if the relevant technology communities agree to > do so" and that for that reason it has to be standards track not BCP. > If it was not being written and pushed by two IESG members, I don't > think we would even be discussing if it should be a BCP. >=20 --------------ms020200010102060400040507 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/ jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q 7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo 98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR 6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV 0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD 0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri 2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6 wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1 nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2 gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1 My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo 6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3 GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6 2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4 TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0 ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+ 39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c 6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2 0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0 H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0 dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTIx NjE1MjIxNlowIwYJKoZIhvcNAQkEMRYEFOkr6cBnNBjHqbadgmyXB2jaIJ76MF8GCSqGSIb3 DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG 9w0BAQEFAASCAQAqM2IG07Oi9nPkw1vdvUnt4EGtxGXuhNxa7XLI41rraC8MoV4MFRYTmjxZ cQf6nRq6xzrKtiXsfXpJbGQ5xfeYG0UVQ9Jf+BuPTsoX/d5sXbDR+R7oxYuEF6AqhVcd5qBw YErWpB+bIfTuL7CLMzUJXK4/Nt2edWxLdRApZ9pf6lUxfjihq6t2e9RhYoQaJ2dumQdq63ej 9E3L2DDF9rh4/1K9bNMMfmY7smvIiI5Jmsjn+S3ZfZNLep+h2SAcG6dNDIweCeoHeRBvxl8/ Y2ftLqNvYwbt8IDUKASYn5zhN9/tugzJFnEGV5IKMNoCsTGSe4DG0qUw5YdSPP0Am+tpAAAA AAAA --------------ms020200010102060400040507-- From sm@resistor.net Fri Dec 17 01:27:18 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 4373B3A6A8D; Fri, 17 Dec 2010 01:27:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.475 X-Spam-Level: X-Spam-Status: No, score=-104.475 tagged_above=-999 required=5 tests=[AWL=1.124, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-1, 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 MIDSg73o6W+y; Fri, 17 Dec 2010 01:27:15 -0800 (PST) Received: from ns1.qubic.net (ns1.qubic.net [208.69.177.116]) by core3.amsl.com (Postfix) with ESMTP id A22693A6926; Fri, 17 Dec 2010 01:27:15 -0800 (PST) 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 oBH9Sl4r013325 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 17 Dec 2010 01:28:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1292578139; x=1292664539; bh=rZAUV6sIh4fGnA+1RQEajgKT1OuqzAfAM9FXAci/9ao=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=xQsPbT5BssCEwFMYKU30Ujgh81OABfgXClMEPb5aBjXoP2PCz/86ue3us79goTiN+ PvfRYyhJ8vV+sn9X5KUnQ7Ae5P0fDOTSbZk29YfLvsIo8mCRnuBoryek7NKwvaN/Qv vkG9q7HEdN88FxHPvhPapehvXHb5T13eiInCvzAE= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1292578139; x=1292664539; bh=rZAUV6sIh4fGnA+1RQEajgKT1OuqzAfAM9FXAci/9ao=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=dR27l4+ZbzpFPydpbCZICUWc5BFl7Bfot2nHL2v+dGonWFneNuqXnwfbagTmS9APR 0sfVTHF/wLqmHi8SAyS2Ale7J0AssAW0pZRoMfjxRVBqIRHnvp8NuCiVRSCzEoKp62 35ucaWpC6rN22WObEwPROsVt2ZLp6+JyTBrameNI= DomainKey-Signature: a=rsa-sha1; s=mail; d=resistor.net; c=simple; q=dns; b=rgM2sMOQrELKGqSr66YWrB90PjrPyHlxFYs5YU3JqixyPhpnhdB33Yq1CXnQGqIlX vrHeZUq4qmOvu4HxKNuGFvAPiobFflpzCFfYknWAhc5qUfAkVdh9vnLwtu7a/hKzbQF DqzNaCK20Eimn72S7Rnnsk5TZEwG2pC2rVyqomg= Message-Id: <6.2.5.6.2.20101217000432.0bd6aea8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 17 Dec 2010 01:28:28 -0800 To: JeffH From: SM In-Reply-To: <4CFFD91A.2060808@KingsMountain.com> References: <4CFFD91A.2060808@KingsMountain.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: draft-saintandre-tls-server-id-check.all@tools.ietf.org, IETF cert-based identity , IETF Discussion List Subject: Re: [certid] Second Last Call: draft-saintandre-tls-server-id-check (...) to BCP 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, 17 Dec 2010 09:27:18 -0000 Hi Jeff, At 11:14 08-12-10, =JeffH wrote: >[ adding certid@ list ] I suggest following up on the certid@ietf.org mailing list and dropping ietf@. >I looked into this in detail earlier this year -- it was discussed >on ietf@ (during the initial IETF LC for this spec), and this >particular issue resolution was summarized here (by John Klensin).. > > Re: Last Call: draft-saintandre-tls-server-id-check > http://www.ietf.org/mail-archive/web/ietf/current/msg62601.html > >In brief summary, RFCs {1034,1035,1123,2181} do not define >"letter-digit-hyphen" DNS name labels in a concisely referenceable >fashion, nor particularly clearly. I'll go with John Klensin's argument for simplicity. >The IDNA specs have done the wider DNS-community a service by doing >so, and at present the fashion in which "traditional domain name" is >defined and cited is the best we can do. Given that IDNs are a >deployed reality, every (new or updated) spec that discusses domain >names going forward is going to need to reference the IDNA specs in >some fashion, and probably should simply use the LDH-Label, A-Label, >and U-Label nomenclature. (IMV) Agreed (in this context). >while I agree with your subtle substitution of.. > > "fully-qualified DNS domain name portion" > >..with.. > > "domain name portion" > >..however, I disagree with your further simplification of that >paragraph because we feel we need to supply the more detailed context. I'll comment on this below. >No, that is not the intent. We've further refined that paragraph as >a result of a concurrent discussion with Ben Campbell (on certid@) >and have this present working text.. > > The client might need to extract the source domain and service type > from the input(s) it has received. The extracted data MUST include > only information that can be securely parsed out of the inputs (e.g., > extracting the fully-qualified DNS domain name from the "authority" > component of a URI or extracting the service type from the scheme of > a URI) or information for which the extraction is performed in a > manner that is not subject to subversion by network attackers (e.g., > pulling the data from a delegated domain that is explicitly > established via client or system configuration, resolving the data > via [DNSSEC], or obtaining the data from a third-party domain mapping > service in which a human user has explicitly placed trust and with > which the client communicates over a connection that provides both > mutual authentication and integrity checking). These considerations > apply only to extraction of the source domain from the inputs; > naturally, if the inputs themselves are invalid or corrupt (e.g., a > user has clicked a link provided by a malicious entity in a phishing > attack), then the client might end up communicating with an > unexpected application service. That sound good. >You mean removing the parenthetical "(following the definition of >"label" from [DNS])", yes? > >In reviewing RFC 1035 I see your concern, tho we'd like to reference >a description of "label". I note that RFC 1034 [S3.1] seems to >appropriately supply this, so I propose we keep the parenthetical >but alter it to be.. > > (following the description of labels and domain names in [DNS-CONCEPTS]) That's fine to me. >Yes, but that definition (and term) appears to be specific to >underlying DNS internals, not to (pseudo) domain names as wielded >(or "presented" (eg in certs)) in other protocols. This brings us to the question of the DNS specific usage of "domain names" and when the term is used in an application context. For example, is the left-most part in "foo*.example.com" ( draft-saintandre-tls-server-id-check-12, Section 5.2) acceptable as a label? I'll react to some comments from Cullen Jennings. At 23:17 15-12-10, Cullen Jennings wrote: >So let me start with I think there is great information in here and >I think it should be published as a standards track RFC however I do >think there are some issues with the relation with this draft and >the realities of what would help improve security in deployment of >SIP, HTTP, IMAP, XMPP etc. The information in draft-saintandre-tls-server-id-check is helpful. It's been a mouthful to comment on the draft as it requires the reading of several referenced documents first. This in itself gives us an idea of the breath this draft tries to cover. >process review. Next this draft contradicts the procedures in >existing protocols and says that it does not apply to the existing >protocols but that it would take precedence over any future updates >of existing protocols that use TLS within the scope specified here. I That begs the question about whether this draft should be a BCP. I would feel more comfortable if such a document is carefully reviewed by people from the different application groups it touches on as it attempts to shape the future. This is not to say that there hasn't been enough discussion about the draft or that it did not get adequate socialization. If the authors are of the opinion that there has been that breath of review, I am fine with that. >In section 3.2, in the imap example, you are saying that if I >configure my imap server to mail.example.com and it presents a >certificate with a DNS-ID of example.com that this is OK. That does >not sound OK to me but I don't know how IMAP works. In the SIP example, the Consider an email address of "user@example.com". The IMAP service is discovered by the MUA by doing a DNS SRV lookup on _imaps.example.com ( draft-daboo-srv-email ) and the target is mail.example.net, i.e that's where the IMAP server is running. The certificate provides a SRV-ID of "_imaps.example.com" and a DNS-ID of "example.com". BTW, the reference to draft-ietf-tls-rfc4366-bis could be normative for the reader to understand SNI and not rely on the workaround for multiple identifiers. Regards, -sm