From stpeter@stpeter.im Mon Jan 3 15:12:19 2011 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 508ED3A6ABA; Mon, 3 Jan 2011 15:12:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.488 X-Spam-Level: X-Spam-Status: No, score=-102.488 tagged_above=-999 required=5 tests=[AWL=0.111, 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 5EA2ZpA7FYeu; Mon, 3 Jan 2011 15:12:17 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id ED1863A6A7E; Mon, 3 Jan 2011 15:12:13 -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 693BD4009B; Mon, 3 Jan 2011 16:28:32 -0700 (MST) Message-ID: <4D22584A.2070307@stpeter.im> Date: Mon, 03 Jan 2011 16:14: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.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Cullen Jennings References: <58FE898B-BD2A-4C6E-B769-256008D8A58B@cisco.com> <4D0A2EA8.6080709@stpeter.im> In-Reply-To: <4D0A2EA8.6080709@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="------------ms070903070809060907030503" 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: Mon, 03 Jan 2011 23:12:19 -0000 This is a cryptographically signed message in MIME format. --------------ms070903070809060907030503 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I just realized that we never replied publicly. Jeff and I had a phone chat with Cullen (and Alexey) about this before the holidays, and we plan to submit a revised I-D this week. Cullen raised some very good points, which we've attempted to address in the forthcoming version. On 12/16/10 8:22 AM, Peter Saint-Andre wrote: > 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 revie= w. >=20 > Peter >=20 > On 12/16/10 12:17 AM, 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. >> >> 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=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. >> >> 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. >> --------------ms070903070809060907030503 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 BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDEw MzIzMTQxOFowIwYJKoZIhvcNAQkEMRYEFPGXCljOGIHx2gXzqC5vrZjqhRegMF8GCSqGSIb3 DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG 9w0BAQEFAASCAQBgRfgYeYfHWdtfwrkhocs5b/qEZ4riNPLsFCOj9f+0tp+x/SbhVRsQ9A7h SREcgUyz+iQCjl9Jza8wPJmysVaFsN5gxiy4G01G0n2g7VaMYi14w4nVh5YQGc/qNbTLqnyC xdO2dstxV7z8DxKOyIn+5EFazK87lyWx6OauzdRS3jK9RbJs09R7b62CFEpn1fcQq/lMJ7yq V3X8M5+9cZT1UjkoB1EgG/yoAcVgt8lxvEr9CZldPAkLVemseB8njb5AekfxGswd0cCXNSem 9KfTsv/PUoolY66z5Frw5PZDzMKTOzOlnjNLFpqpXgxNEN8vkbnq0L4PHF1xk7RHef4nAAAA AAAA --------------ms070903070809060907030503-- From stpeter@stpeter.im Wed Jan 5 10:03:07 2011 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 4B4923A6CE5; Wed, 5 Jan 2011 10:03:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.498 X-Spam-Level: X-Spam-Status: No, score=-102.498 tagged_above=-999 required=5 tests=[AWL=0.101, 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 F2a2Nzpzju01; Wed, 5 Jan 2011 10:03:05 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 45D8B3A6C9F; Wed, 5 Jan 2011 10:03:05 -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 A68244009B; Wed, 5 Jan 2011 11:19:32 -0700 (MST) Message-ID: <4D24B2D5.6060709@stpeter.im> Date: Wed, 05 Jan 2011 11:05: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.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Cullen Jennings References: <58FE898B-BD2A-4C6E-B769-256008D8A58B@cisco.com> <4D0A2EA8.6080709@stpeter.im> <4D22584A.2070307@stpeter.im> In-Reply-To: <4D22584A.2070307@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="------------ms070509000902060800050103" 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: Wed, 05 Jan 2011 18:03:07 -0000 This is a cryptographically signed message in MIME format. --------------ms070509000902060800050103 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Done: http://www.ietf.org/id/draft-saintandre-tls-server-id-check-13.txt The diff from -12 is here: http://tools.ietf.org/rfcdiff?url2=3Ddraft-saintandre-tls-server-id-check= -13 Peter On 1/3/11 4:14 PM, Peter Saint-Andre wrote: > I just realized that we never replied publicly. Jeff and I had a phone > chat with Cullen (and Alexey) about this before the holidays, and we > plan to submit a revised I-D this week. Cullen raised some very good > points, which we've attempted to address in the forthcoming version. >=20 > On 12/16/10 8:22 AM, Peter Saint-Andre wrote: >> Thanks for your comments. My co-author and I will need to confer befor= e >> replying, and that might take a few days given the length of your revi= ew. >> >> Peter >> >> On 12/16/10 12:17 AM, 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. >>> >>> 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=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. >>> >>> 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. >>> --------------ms070509000902060800050103 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 BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDEw NTE4MDUwOVowIwYJKoZIhvcNAQkEMRYEFL5lyBis3AiteY0AR3CWP99gQGKEMF8GCSqGSIb3 DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG 9w0BAQEFAASCAQBlegfgmwP+IaLrJYtzBKnXi1GkE0x7Jm4K/BsYEkoOulgTZI37t4ySox1X pxWpow6KzxMVsJs8V4zv3zXTkK1+32llW7IUFyrJTmYGO0SGtVyqesJb6EISFzN3ZiCeLwHv /A2r2LNY5PJh/ZWwAFMBK8CZGJZ89NlQ+qu/PLZugknHRCDZkkqz5FR4xuVxv7u7OJb1N6cX O0NncTbD/nuotDIYMS0DbAe0BWtfWyC2BXp1BdBJyv170jmvn0JUt44X5+GPJ/RbDO3mz43L YtcYT6YAwk+IgAJSaKnojgZs/ZUs218zDUGj3wis8ba61nBOoQ3yG7JERS6hitz0Qn7YAAAA AAAA --------------ms070509000902060800050103-- From stpeter@stpeter.im Wed Jan 12 16:29:18 2011 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 3155E3A67AE for ; Wed, 12 Jan 2011 16:29:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.504 X-Spam-Level: X-Spam-Status: No, score=-102.504 tagged_above=-999 required=5 tests=[AWL=0.095, 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 8a06G7JB3Pjk for ; Wed, 12 Jan 2011 16:29:17 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 23F373A67E2 for ; Wed, 12 Jan 2011 16:29:17 -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 B8465400EE for ; Wed, 12 Jan 2011 17:46:38 -0700 (MST) Message-ID: <4D2E47E7.9050604@stpeter.im> Date: Wed, 12 Jan 2011 17:31:35 -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="------------ms020904070703080807060505" Subject: [certid] version -14 X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2011 00:29:18 -0000 This is a cryptographically signed message in MIME format. --------------ms020904070703080807060505 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Folks, based on feedback from Cullen Jennings and Alexey Melnikov, Jeff and I have made some relatively small edits to the server-id-check spec: http://www.ietf.org/id/draft-saintandre-tls-server-id-check-14.txt The diff is here: http://tools.ietf.org/rfcdiff?url2=3Ddraft-saintandre-tls-server-id-check= -14 This document is on the agenda for the next Thursday's IESG telechat. Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms020904070703080807060505 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 BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDEx MzAwMzEzNVowIwYJKoZIhvcNAQkEMRYEFFG7qTb7ApfgWZDd4fTsNsWnQQu+MF8GCSqGSIb3 DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG 9w0BAQEFAASCAQCAMh0vsYHmdpo7bhwa9YpcII745dfrqZ7lTuHYBldTLDtGqWrBuj8Thk7k U3SplbHSWm9quZTeZsSW7PUCh9CTI7+cdCXG3tPdteNKx/4s/jv7GPJ+l0vWrj8Tq74wLndI XTGkEVdQlSChK+QBy5QgmRVeYdFpzBoOxmLXEJcJIOGuwV041Vgrx5xK1X1aKJH9ollyPewL 0M+2BDCZvC2KSo+z5SW5jCldkkLrs7M23SGzauFpeKfUe3dHkJEox1ExY2pVds6qO3b0gcLt 2aQNAD8QoDIUGcJQIpP+p2ZtB4WRtbT0ya7v8zQDfgavE4FAQ45JHLLRHAy25B0NLhWIAAAA AAAA --------------ms020904070703080807060505-- From Jeff.Hodges@KingsMountain.com Mon Jan 17 07:18:56 2011 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 3CA163A6F3F for ; Mon, 17 Jan 2011 07:18:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.97 X-Spam-Level: X-Spam-Status: No, score=-100.97 tagged_above=-999 required=5 tests=[AWL=-1.305, BAYES_50=0.001, 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 hoB8BAOzjdJm for ; Mon, 17 Jan 2011 07:18:55 -0800 (PST) Received: from cpoproxy1-pub.bluehost.com (cpoproxy1-pub.bluehost.com [69.89.21.11]) by core3.amsl.com (Postfix) with SMTP id 402443A6F3E for ; Mon, 17 Jan 2011 07:18:55 -0800 (PST) Received: (qmail 31698 invoked by uid 0); 17 Jan 2011 15:21:29 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by cpoproxy1.bluehost.com with SMTP; 17 Jan 2011 15:21:29 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kingsmountain.com; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=Opfr6IENJH+hKolju/rOrSofgA3lST3k+UiMijs1ckOhdEukNAKuwTXHeHpBuJ4Rjm6qVN8iPgxU1MHMWnu8rseRBaVaYc6xR1dHzVsVnMQ1d5zSuSoGvkOR2zD/vKG/; 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 1Peqtd-0008AE-9O for certid@ietf.org; Mon, 17 Jan 2011 08:21:29 -0700 Message-ID: <4D345E76.1080300@KingsMountain.com> Date: Mon, 17 Jan 2011 07:21:26 -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] fyi: EFF (TLS/)SSL Observatory discussion list 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, 17 Jan 2011 15:18:56 -0000 fyi: https://mail1.eff.org/mailman/listinfo/observatory " A public forum to discuss the results and datasets of the EFF SSL (and TLS) Observatory, https://eff.org/observatory " Chris Palmer adds: [the list is for] "discussing general global PKI fact-finding research, results, and implications" HTH, =JeffH From Peter.SaintAndre@webex.com Mon Jan 17 08:21:42 2011 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 9F6C23A6E4D for ; Mon, 17 Jan 2011 08:21:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rX3cs5T+qhMZ for ; Mon, 17 Jan 2011 08:21:41 -0800 (PST) Received: from gw1.webex.com (gw1.webex.com [64.68.122.208]) by core3.amsl.com (Postfix) with SMTP id C497E3A6B94 for ; Mon, 17 Jan 2011 08:21:41 -0800 (PST) Received: from SRV-EXSC03.webex.local ([192.168.252.197]) by gw1.webex.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 17 Jan 2011 08:24:16 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 17 Jan 2011 08:24:14 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Lars Eggert's No Objection ondraft-saintandre-tls-server-id-check-14: (with COMMENT) Thread-Index: Acu2RBgxyUyHnYUQSJWDC8WxMPXPDAAHuMVK From: "Peter Saint Andre" To: X-OriginalArrivalTime: 17 Jan 2011 16:24:16.0520 (UTC) FILETIME=[FC3E9080:01CBB662] Subject: [certid] Fw: Lars Eggert's No Objection ondraft-saintandre-tls-server-id-check-14: (with COMMENT) 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, 17 Jan 2011 16:21:42 -0000 FYI. ----- Original Message ----- From: Lars Eggert To: The IESG Cc: kurt.zeilenga@isode.com ; = Jeff.Hodges@KingsMountain.com ; = psaintan@cisco.com ; = draft-saintandre-tls-server-id-check@tools.ietf.org = Sent: Mon Jan 17 04:40:22 2011 Subject: Lars Eggert's No Objection = ondraft-saintandre-tls-server-id-check-14: (with COMMENT) Lars Eggert has entered the following ballot position for draft-saintandre-tls-server-id-check-14: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Section 1.5., paragraph 8: > These suggestions are not entirely consistent with all practices = that > are currently followed by certification authorities, client > developers, and service providers. However, they reflect the best > aspects of current practices and are expected to become more widely > adopted in the coming years. This seems to argue that the doc should be a BCP and not a PS? Section 1.8., paragraph 28: > Transport Layer Security [TLS] negotiation; in this specfication Nit: s/specfication/specification/ Appendix A., paragraph 1: > recommendations in this specfication: email [EMAIL-SRV] and XMPP Nit: s/specfication:/specification:/ Section 7.2., paragraph 1: > Implemenations MUST NOT match any form of wildcard, such as a Nit: s/Implemenations/Implementations/ From matt@mattmccutchen.net Mon Jan 17 11:10:32 2011 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 90AAF3A6EE1 for ; Mon, 17 Jan 2011 11:10:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.756 X-Spam-Level: X-Spam-Status: No, score=-1.756 tagged_above=-999 required=5 tests=[AWL=-0.646, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NmAUqKBWxO09 for ; Mon, 17 Jan 2011 11:10:31 -0800 (PST) Received: from homiemail-a61.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by core3.amsl.com (Postfix) with ESMTP id 9C57C3A6E5C for ; Mon, 17 Jan 2011 11:10:31 -0800 (PST) Received: from homiemail-a61.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a61.g.dreamhost.com (Postfix) with ESMTP id 9C51E57806C for ; Mon, 17 Jan 2011 11:13:06 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:content-type:date:message-id:mime-version: content-transfer-encoding; q=dns; s=mattmccutchen.net; b=ixtBoeO KlYb9/ngmWRQujyWuM3qBmAwXz2C16NsehAqR/bvgdp+0dMuCY45zZ8UAR1I0lz4 ePDgfG7niO3gKS2g+whhSh+HmDDNhw0MK/XgfRp6ZCSVO1N6DBsUqPUjPf2PdSpO O3qQ/rJDReOjsbxM6rYe69gCG0TYE1koLNBk= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:content-type:date:message-id:mime-version: content-transfer-encoding; s=mattmccutchen.net; bh=VQ762X2XpV45G ujQ3YT6Aoo7ZS0=; b=BfWnIl2OGt6W2OnoBTt4vW4TsK0hSC3JH48Fz2lJu2hD+ 0ytjJhZO/WrvKntONYPu9IPKYgEa45TM/dRHq9hynmD0BuhGP230WeGbJDnimTk9 wMAle39iPMtcd1znlg1VP/ATrRvn5j5KgIbo2M4jRXcVpapbfpm/Ydn3IZUgMw= Received: from [192.168.1.40] (pool-74-96-47-53.washdc.east.verizon.net [74.96.47.53]) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a61.g.dreamhost.com (Postfix) with ESMTPA id 2D64A578073 for ; Mon, 17 Jan 2011 11:13:06 -0800 (PST) From: Matt McCutchen To: certid@ietf.org Content-Type: text/plain; charset="UTF-8" Date: Mon, 17 Jan 2011 14:13:04 -0500 Message-ID: <1295291584.2221.18.camel@mattlaptop2.local> Mime-Version: 1.0 X-Mailer: Evolution 2.32.2 Content-Transfer-Encoding: 7bit Subject: [certid] What security does SRV-ID add when DNS-ID will always match? 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, 17 Jan 2011 19:10:32 -0000 The use of SRV-IDs is supposed to ensure that the client connects to the service type it wanted from among the services available at the DNS name it wanted. However, given that... - The client's list of reference identifiers MUST include a DNS-ID (section 6.2.10) - The examples of server certificates that include a SRV-ID (section 4.2) also include a DNS-ID - The server ID check succeeds if any reference identifier matches any presented identifier (section 6.3) it would appear that the DNS-IDs will always match, making the service types in the SRV-IDs irrelevant. Am I right? -- Matt From Jeff.Hodges@KingsMountain.com Mon Jan 17 11:55:21 2011 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 0F57C28C174 for ; Mon, 17 Jan 2011 11:55:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.392 X-Spam-Level: X-Spam-Status: No, score=-102.392 tagged_above=-999 required=5 tests=[AWL=0.207, 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 db4OC4ZpJ-l9 for ; Mon, 17 Jan 2011 11:55:19 -0800 (PST) Received: from oproxy1-pub.bluehost.com (oproxy1-pub.bluehost.com [66.147.249.253]) by core3.amsl.com (Postfix) with SMTP id CF0C23A6DB6 for ; Mon, 17 Jan 2011 11:55:19 -0800 (PST) Received: (qmail 23716 invoked by uid 0); 17 Jan 2011 19:57:54 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy1.bluehost.com.bluehost.com with SMTP; 17 Jan 2011 19:57:54 -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=qRXjTu8OrviJ3Q0JsQ/Cc0rw+CLOR3B7gkOenpLq6BoKFgTiwF/K/wW0uOQ6qOcSRfdb2UsceD9Ss8kw9YsD0L+KEQtpLR406JVM+HHreT3EM+pXm/N+vbdJSJpXjJys; 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 1PevD8-0000Ok-Db for certid@ietf.org; Mon, 17 Jan 2011 12:57:54 -0700 Message-ID: <4D349F3E.3060601@KingsMountain.com> Date: Mon, 17 Jan 2011 11:57:50 -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: Re: [certid] What security does SRV-ID add when DNS-ID will always match? 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, 17 Jan 2011 19:55:21 -0000 > The use of SRV-IDs is supposed to ensure that the client connects to the > service type it wanted from among the services available at the DNS name > it wanted. However, given that... > > - The client's list of reference identifiers MUST include a DNS-ID > (section 6.2.10) you mean S6.2.1, yes? > - The examples of server certificates that include a SRV-ID (section > 4.2) also include a DNS-ID > - The server ID check succeeds if any reference identifier matches any > presented identifier (section 6.3) > > it would appear that the DNS-IDs will always match, making the service > types in the SRV-IDs irrelevant. Am I right? thx for the headsup, but I don't think so, see section 6.5... ### 6.5. Matching the Application Type Portion If a client supports checking of identifiers of type SRV-ID and URI-ID, it MUST also check the service type of the application service with which it communicates (in addition to checking the domain name as described above). This is a best practice because typically a client is not designed to communicate with all kinds of services using all possible application protocols, but instead is designed to communicate with one kind of service, such as websites, email services, VoIP services, or IM services. The service type is verified by means of an SRV-ID or a URI-ID. 6.5.1. SRV-ID The service name portion of an SRV-ID (e.g., "imaps") MUST be matched in a case-insensitive manner, in accordance with [DNS-SRV]. Note that the "_" character is prepended to the service identifier in DNS SRV records and in SRV-IDs (per [SRVNAME]), and thus does not need to be included in any comparison. 6.5.2. URI-ID The scheme name portion of a URI-ID (e.g., "sip") MUST be matched in a case-insensitive manner, in accordance with [URI]. Note that the ":" character is a separator between the scheme name and the rest of the URI, and thus does not need to be included in any comparison. ### I note that we should fix the S6.5 title to be.. "Matching the Application Service Type Portion" ..or simply.. "Matching the Application Service Type" thanks, =JeffH From matt@mattmccutchen.net Mon Jan 17 12:52:48 2011 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 93C2528C162 for ; Mon, 17 Jan 2011 12:52:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.424 X-Spam-Level: X-Spam-Status: No, score=-2.424 tagged_above=-999 required=5 tests=[AWL=0.175, 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 aHKSUlUGm4eE for ; Mon, 17 Jan 2011 12:52:46 -0800 (PST) Received: from homiemail-a4.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by core3.amsl.com (Postfix) with ESMTP id 5533328C157 for ; Mon, 17 Jan 2011 12:52:46 -0800 (PST) Received: from homiemail-a4.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a4.g.dreamhost.com (Postfix) with ESMTP id 6A65B51C06C; Mon, 17 Jan 2011 12:55:21 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:cc:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; q=dns; s= mattmccutchen.net; b=eOWAhS2v8DX2mZLyfnceodzLUpQzlyIQkkJvzTMMVG6 bUMflHrkglVViY95xJITygosBbjSe6OI+W9J3klIQ8Worn8vftOLFFSV5fYkp5YT tw+hneOh4K7bNmOCB6J0LTFxqUbTBLI9jS0fbUGe+9F/Hscu+CG0br5/YGoBWuvg = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:content-transfer-encoding; s= mattmccutchen.net; bh=e9VoEZ4YHkqfpxbUJnudQOHtn1I=; b=glaz63Yaqk hGcZxfdQWAMeHE69CGpoM0buXtbwl9EyXoBQB6fdQwLdstk2f3UWja8ismexYDnP Ukt2BZbq2ziAH3qmZe+5gFn6pEx1fm99PDQea6k3uDz4BmQABB0QD9hl/6M6dGQC TUL2v+LqhdOxp7zQlcdEyDzpp41QXXs7A= Received: from [192.168.1.40] (pool-74-96-47-53.washdc.east.verizon.net [74.96.47.53]) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a4.g.dreamhost.com (Postfix) with ESMTPA id D7D6C51C063; Mon, 17 Jan 2011 12:55:20 -0800 (PST) From: Matt McCutchen To: =JeffH In-Reply-To: <4D349F3E.3060601@KingsMountain.com> References: <4D349F3E.3060601@KingsMountain.com> Content-Type: text/plain; charset="UTF-8" Date: Mon, 17 Jan 2011 15:55:19 -0500 Message-ID: <1295297719.2221.81.camel@mattlaptop2.local> Mime-Version: 1.0 X-Mailer: Evolution 2.32.2 Content-Transfer-Encoding: 7bit Cc: IETF cert-based identity Subject: Re: [certid] What security does SRV-ID add when DNS-ID will always match? 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, 17 Jan 2011 20:52:48 -0000 On Mon, 2011-01-17 at 11:57 -0800, =JeffH wrote: > > The use of SRV-IDs is supposed to ensure that the client connects to the > > service type it wanted from among the services available at the DNS name > > it wanted. However, given that... > > > > - The client's list of reference identifiers MUST include a DNS-ID > > (section 6.2.10) > > you mean S6.2.1, yes? Yes (typo) > > - The examples of server certificates that include a SRV-ID (section > > 4.2) also include a DNS-ID > > - The server ID check succeeds if any reference identifier matches any > > presented identifier (section 6.3) > > > > it would appear that the DNS-IDs will always match, making the service > > types in the SRV-IDs irrelevant. Am I right? > > thx for the headsup, but I don't think so, see section 6.5... > > ### > > 6.5. Matching the Application Type Portion > > > If a client supports checking of identifiers of type SRV-ID and > URI-ID, it MUST also check the service type of the application > service with which it communicates (in addition to checking the > domain name as described above). [...] > ### Maybe I am misunderstanding how that section applies. Let's consider an example. Reference identifiers: 1. SRV-ID _imaps.example.net 2. DNS-ID example.net Presented identifiers: 3. SRV-ID _xmpp-server.example.net 4. DNS-ID example.net The client checks each reference identifier against each presented identifier (section 6.3). #1 and #3: The service types differ, so no match. #1 and #4: One identifier specifies a service type and the other doesn't. The behavior in this case is not spelled out, but I would assume there is no match. #2 and #3: Ditto. #2 and #4: Neither identifier specifies service type, and the DNS names are the same. Is this a match? If so, we get the problem I originally described. Are you saying that a client that "supports checking of identifiers of type SRV-ID and URI-ID" MUST NOT compare two DNS-IDs, because they do not contain the service type information that the client is required to check? If so, then in the following example: Reference identifiers: 1. SRV-ID _imaps.example.net 2. DNS-ID example.net Presented identifiers: 4. DNS-ID example.net we would get "no match", when it seems a match would be helpful for backward compatibility. -- Matt From matt@mattmccutchen.net Mon Jan 17 12:57:04 2011 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 2DE5B28C155 for ; Mon, 17 Jan 2011 12:57:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[AWL=0.162, 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 V1cRDm0rtWJi for ; Mon, 17 Jan 2011 12:57:02 -0800 (PST) Received: from homiemail-a3.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by core3.amsl.com (Postfix) with ESMTP id E556628C145 for ; Mon, 17 Jan 2011 12:57:02 -0800 (PST) Received: from homiemail-a3.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a3.g.dreamhost.com (Postfix) with ESMTP id 2C11F284078; Mon, 17 Jan 2011 12:59:38 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:cc:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; q=dns; s= mattmccutchen.net; b=aaA90k5KxofCBh8j3FxVYEBsGVBezlrSNTK+36MeEAz LiNDCXDRAAgoK+ufRS04i02OQCK1/a3HeVbYhN8g186unfzgjTXScgm09SARRCak zDI+YAvT2fVPTiw+3Rm+EhArxpl45W01z4sK5pZK/Oxu1eCPovXRrDGyYubq9ryg = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:content-transfer-encoding; s= mattmccutchen.net; bh=kO5X7fDJO35BErGWNapvPmKGI8E=; b=AS1n4bik+8 NRJGtSjr3Mo4u3rFI4mPyoY+LoHzP+t/Xlds3N5ExI5lB2sx51PVXSNyrCWu31xR /XxiSTPbrA0/s1kaIb+wPiQbN8SdfK38UJnRlzTxenYjXTxkeXpHG/wNyoSzZA1w EftujTKtD34fmGmmTG24T2kejFyOx2Wp8= Received: from [192.168.1.40] (pool-74-96-47-53.washdc.east.verizon.net [74.96.47.53]) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a3.g.dreamhost.com (Postfix) with ESMTPA id A5B6A284071; Mon, 17 Jan 2011 12:59:37 -0800 (PST) From: Matt McCutchen To: Peter Saint Andre In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Date: Mon, 17 Jan 2011 15:59:36 -0500 Message-ID: <1295297976.2221.83.camel@mattlaptop2.local> Mime-Version: 1.0 X-Mailer: Evolution 2.32.2 Content-Transfer-Encoding: 7bit Cc: certid@ietf.org Subject: Re: [certid] Fw: Lars Eggert's No Objection ondraft-saintandre-tls-server-id-check-14: (with COMMENT) 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, 17 Jan 2011 20:57:04 -0000 On Mon, 2011-01-17 at 08:24 -0800, Peter Saint Andre wrote: > Section 1.5., paragraph 8: > > These suggestions are not entirely consistent with all practices that > > are currently followed by certification authorities, client > > developers, and service providers. However, they reflect the best > > aspects of current practices and are expected to become more widely > > adopted in the coming years. > > This seems to argue that the doc should be a BCP and not a PS? Round we go again... AIUI, the document needs to be a PS because it defines matching rules intended for incorporation into application protocol PSes. Correct? -- Matt From stpeter@stpeter.im Tue Jan 18 09:38:31 2011 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 7E60C3A6F6C for ; Tue, 18 Jan 2011 09:38:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 HEpydGGozu4L for ; Tue, 18 Jan 2011 09:38:29 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 40CFF3A7021 for ; Tue, 18 Jan 2011 09:38:27 -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 4E2C940393; Tue, 18 Jan 2011 10:56:36 -0700 (MST) Message-ID: <4D35D0B0.2050806@stpeter.im> Date: Tue, 18 Jan 2011 10:41: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.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Matt McCutchen References: <1295297976.2221.83.camel@mattlaptop2.local> In-Reply-To: <1295297976.2221.83.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="------------ms070307040600090004050204" Cc: Peter Saint Andre , certid@ietf.org Subject: Re: [certid] Fw: Lars Eggert's No Objection ondraft-saintandre-tls-server-id-check-14: (with COMMENT) 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, 18 Jan 2011 17:38:31 -0000 This is a cryptographically signed message in MIME format. --------------ms070307040600090004050204 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 1/17/11 1:59 PM, Matt McCutchen wrote: > On Mon, 2011-01-17 at 08:24 -0800, Peter Saint Andre wrote: >> Section 1.5., paragraph 8: >>> These suggestions are not entirely consistent with all practices t= hat >>> are currently followed by certification authorities, client >>> developers, and service providers. However, they reflect the best= >>> aspects of current practices and are expected to become more widel= y >>> adopted in the coming years. >> >> This seems to argue that the doc should be a BCP and not a PS? >=20 > Round we go again... AIUI, the document needs to be a PS because it > defines matching rules intended for incorporation into application > protocol PSes. Correct? This will likely be discussed on the IESG telechat this week. However, Cullen Jennings and Robert Sparks have me convinced that PS is correct. Jeff and I discussed this with Alexey, too. Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms070307040600090004050204 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 BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDEx ODE3NDEwNFowIwYJKoZIhvcNAQkEMRYEFFrG0LpzXVZ0Sh7VnYKa3RDuBQwnMF8GCSqGSIb3 DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG 9w0BAQEFAASCAQCWiCeAOZV24y1icrKRfoQ8DtrRCd7ftHRU1LANrErz1RXSimGOv9FUSISk xkIGpPD8w4teSejYF4X6guuokbBr9r/rvqWNMJth5+aSVidO2qjjrFGaeFiK8GkQ07oUOsw/ KPOW7eSKH9GiZjsrGbCCDUJHFndd7yBmh5vCPlihgrMSp2V6kfZMSaHotQ2v2kmRZPkaZ0M8 dUybgPbZJ/fsBzyozRwGUeOChhdZtlwbnBfxwbwrWp50CJ2ctfGXhm/m8IPbOVrX65bvR9A3 ijf5W2xGrvW6F6kod6VdtuU1PV68UbLhtEEEKPnCsgR+R26sH7yXYZsuYzR41bLe9KqDAAAA AAAA --------------ms070307040600090004050204-- From Jeff.Hodges@KingsMountain.com Tue Jan 18 11:51:47 2011 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 373113A6E5D for ; Tue, 18 Jan 2011 11:51:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.081 X-Spam-Level: X-Spam-Status: No, score=-102.081 tagged_above=-999 required=5 tests=[AWL=0.184, 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 HmMgtzcTDEhQ for ; Tue, 18 Jan 2011 11:51:46 -0800 (PST) Received: from cpoproxy1-pub.bluehost.com (cpoproxy1-pub.bluehost.com [69.89.21.11]) by core3.amsl.com (Postfix) with SMTP id CE5753A6EE1 for ; Tue, 18 Jan 2011 11:51:41 -0800 (PST) Received: (qmail 31324 invoked by uid 0); 18 Jan 2011 19:54:19 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by cpoproxy1.bluehost.com with SMTP; 18 Jan 2011 19:54:19 -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=8CKlpv7g6GuGazzmqL6EFRa2xG5FVeVnTE9bp+WHLcsXtBK/IpMy42XvJkhDYZ9Loz+9KS1J9sQ4m49XSHLpPSyA3wMR0dl9xOCo8SVpEL2wvVlwB3WF2uV/aV1WgcUN; Received: from outbound4.ebay.com ([216.113.168.128] helo=[10.244.136.134]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1PfHdD-0004xI-4f for certid@ietf.org; Tue, 18 Jan 2011 12:54:19 -0700 Message-ID: <4D35EFE7.4060209@KingsMountain.com> Date: Tue, 18 Jan 2011 11:54:15 -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 216.113.168.128 authed with jeff.hodges+kingsmountain.com} Subject: Re: [certid] What security does SRV-ID add when DNS-ID will always match? 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, 18 Jan 2011 19:51:47 -0000 > On Mon, 2011-01-17 at 11:57 -0800, =JeffH wrote: > [...] > >> > - The examples of server certificates that include a SRV-ID (section >> > 4.2) also include a DNS-ID >> > - The server ID check succeeds if any reference identifier matches any >> > presented identifier (section 6.3) >> > >> > it would appear that the DNS-IDs will always match, making the service >> > types in the SRV-IDs irrelevant. Am I right? >> >> thx for the headsup, but I don't think so, see section 6.5... >> >> ### >> >> 6.5. Matching the Application Type Portion >> >> >> If a client supports checking of identifiers of type SRV-ID and >> URI-ID, it MUST also check the service type of the application >> service with which it communicates (in addition to checking the >> domain name as described above). > [...] >> ### > > Maybe I am misunderstanding how that section applies. Let's consider an > example. > > Reference identifiers: > 1. SRV-ID _imaps.example.net > 2. DNS-ID example.net However, according to 3d bullet of S6.3, the client would effectively do this with #1.. 1. _imaps.example.net => DNS domain name portion: "example.net" service type portion: "imaps" ..before proceeding with seeking a match. > Presented identifiers: > 3. SRV-ID _xmpp-server.example.net Also, the spec implies that the client would effectively do this with #3.. 3. SRV-ID _xmpp-server.example.net => DNS domain name portion: "example.net" service type portion: "xmpp-server" (the spec could probably be more clear about this) > 4. DNS-ID example.net > > The client checks each reference identifier against each presented > identifier (section 6.3). > > #1 and #3: The service types differ, so no match. > #1 and #4: One identifier specifies a service type and the other > doesn't. The behavior in this case is not spelled out, but I would > assume there is no match. > #2 and #3: Ditto. > #2 and #4: Neither identifier specifies service type, and the DNS names > are the same. Is this a match? If so, we get the problem I originally > described. The matching details in this example isn't exactly what is intended by the spec (but is perhaps not presented as clearly as it should be). I've added details here.. #1 and #3: first, the DNS domain name portions "example.net" match. However, the service type portions of "imaps" and "xmpp-server" don't match (we note in the spec that one ought to ignore the "_" char in SRV-ID service type portions). So #1 & #3 don't match. #1 and #4: first, the DNS domain name portion "example.net" match, but #4 doesn't have a service type portion so no match. #2 and #3: same as #1 and #4. #2 and #4: the DNS domain name portions "example.net" match. However, the "MUST" clause in S6.5 quoted above holds and thus this match between #2 and #4 is insufficient on its own to declare a match. > Are you saying that a client that "supports checking of identifiers of > type SRV-ID and URI-ID" MUST NOT compare two DNS-IDs, because they do > not contain the service type information that the client is required to > check? If so, then in the following example: > > Reference identifiers: > 1. SRV-ID _imaps.example.net > 2. DNS-ID example.net > > Presented identifiers: > 4. DNS-ID example.net > > we would get "no match", when it seems a match would be helpful for > backward compatibility. I think we may have intended to allow for the latter with the "SHOULD" clause of the 2nd bullet of S6.2.1.. o If a server for the service type is typically discovered by means of DNS SRV records, then the list SHOULD include an SRV-ID. ..i.e. if the client wishes to be more lenient in what presented idents it checks against, it could leave the reference SRV-ID off it's list of reference idents to use to check against the presented idents. And so the resultant behavior is ambiguous given the way S6.5's "MUST" clause is crafted where it says "If a client supports checking of identifiers of type SRV-ID..." It should probably say something like.. If a client supports checking of identifiers of type SRV-ID or URI-ID, and identifiers of those type(s) are included in the reference identifier list, then it MUST also check the service type... so yes, good catch, thanks, =JeffH From stpeter@stpeter.im Thu Jan 20 18:18:16 2011 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 83B5E3A680E for ; Thu, 20 Jan 2011 18:18:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 W8Glq43YsLFu for ; Thu, 20 Jan 2011 18:18:15 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 5ED9B3A67D1 for ; Thu, 20 Jan 2011 18:18:15 -0800 (PST) Received: from squire.local (dsl-251-175.dynamic-dsl.frii.net [216.17.251.175]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id C86F6400EE for ; Thu, 20 Jan 2011 19:36:43 -0700 (MST) Message-ID: <4D38ED89.9070208@stpeter.im> Date: Thu, 20 Jan 2011 19:20:57 -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="------------ms000801020402060209060305" Subject: [certid] IESG approval of draft-saintandre-tls-server-id-check-14 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, 21 Jan 2011 02:18:16 -0000 This is a cryptographically signed message in MIME format. --------------ms000801020402060209060305 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable During its telechat earlier today, the IESG approved version -14 of draft-saintandre-tls-server-id-check as a Proposed Standard (not BCP). I'll leave it to Alexey Melnikov, our sponsoring area director, to explain the details about where we go from here (e.g., possible incorporation of small text modifications resulting from the discussion thread between Matt McCutchen and Jeff Hodges over the last 3 days). For myself, I fully expect to be working on a bis draft at some point in the next few years, because I don't think that this I-D is quite the final word on the topic. However, I do think it brings us closer to wide consensus regarding application service identity, and that perhaps the bis draft could be a true BCP (developed, I would think, within the TLS W= G). Thanks to everyone who contributed to and provided feedback on this document -- your input is very much appreciated! Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms000801020402060209060305 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 BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDEy MTAyMjA1N1owIwYJKoZIhvcNAQkEMRYEFBe4a/TrcQf7ofYBaa9AMEt6Ay6YMF8GCSqGSIb3 DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG 9w0BAQEFAASCAQBoN1ftOZ6LBLD7mLyGkhbNbk4edlGtn6ab06e8xG0uJp6J/WBb/g0ud//l EI4QLc4kVFAisPCjt4yRsnFVBAY2/QdHms2S3HVd3cZs8nZXa9KkJdnQ6olRgjVVww5gF7CE NHXT9aoKrzHtKSOBK2yelsqfCxSKzcKOcsp9PX/auKWmTlKrj4ONgF/rApbIbfEuKJ3Jrv3c MO+Ow1Nj/NuZDDYOnfDJTolwytKYdsDkm2YpQt8Xp88WoDxDb11kax3vKi1OAxAMVYl7rYUT ho30hSJ+nOI9aJCldWgWTU7IvRvj198w0fZLHOpaIo4YKdBYB+rB97MZ6y7/P/QdlGGXAAAA AAAA --------------ms000801020402060209060305-- From Jeff.Hodges@KingsMountain.com Fri Jan 21 17:05:02 2011 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 368EB3A6877 for ; Fri, 21 Jan 2011 17:05:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.231 X-Spam-Level: X-Spam-Status: No, score=-102.231 tagged_above=-999 required=5 tests=[AWL=0.034, 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 llMa-yaX+Pqm for ; Fri, 21 Jan 2011 17:05:01 -0800 (PST) Received: from cpoproxy1-pub.bluehost.com (cpoproxy1-pub.bluehost.com [69.89.21.11]) by core3.amsl.com (Postfix) with SMTP id 093A23A685D for ; Fri, 21 Jan 2011 17:05:01 -0800 (PST) Received: (qmail 6615 invoked by uid 0); 22 Jan 2011 01:07:48 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by cpoproxy1.bluehost.com with SMTP; 22 Jan 2011 01:07:48 -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=bTIP8HcmwQNNh98XAeamVIQKTWGkBbkw0Q/+rg8bLlXFG1jR8grDMcrlMiwzh7TsWQHE4pVtAfYC+Nm9Jz3OqdovxirDAXTTp8F8SbCpIh6GUvawKzWVKFwQwtadsB1i; 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 1PgRxD-0001lc-R5; Fri, 21 Jan 2011 18:07:48 -0700 Message-ID: <4D3A2DE2.4050304@KingsMountain.com> Date: Fri, 21 Jan 2011 17:07:46 -0800 From: =JeffH User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: SM 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: IETF cert-based identity 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: Sat, 22 Jan 2011 01:05:02 -0000 Hi SM, apologies for latency in replying.. >>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. k > >>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? No, "foo*" isn't a legit dns label per se. However, it's only used in "presented" domain names in various contexts -- certs being one -- and intended for matching within applications, not for actual dereferencing via the DNS. > 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. above is no longer an issue as the draft is now approved as a proposed std. thx for the input on the issue in any case. > >>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". we've incorp'd such an example in the draft, thx. > > 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. we don't feel its approp at this time to make that a normative reference, for at least the reasons given in the draft in S7.4. thanks again for your review, =JeffH From sm@resistor.net Mon Jan 24 13:49:02 2011 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 4E6063A6967 for ; Mon, 24 Jan 2011 13:49:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.428 X-Spam-Level: X-Spam-Status: No, score=-102.428 tagged_above=-999 required=5 tests=[AWL=-1.243, BAYES_40=-0.185, 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 RIFqc4W+RhdG for ; Mon, 24 Jan 2011 13:49:00 -0800 (PST) Received: from ns1.qubic.net (ns1.qubic.net [208.69.177.116]) by core3.amsl.com (Postfix) with ESMTP id CF7663A68EE for ; Mon, 24 Jan 2011 13:49:00 -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 p0OLplhk023965 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 24 Jan 2011 13:51:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1295905915; x=1295992315; bh=iLDsV7QT5cBP6gMcho7ZG5D3Ig8mIcR85D1gWIWUURE=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=3h/V4QASbqQNd8XKH6WfvPJY5JoE9CQYxKxMePrlTbxK+C7o2ou6nlJ23Jv0tv8cP K2hVfGOwF56QevNDITkfJTCBap43hSRg9fyxlmgYYXMRzj2iaZTegxKJg/9YX0sLvS fvqqwP+F8SHRRCgbcBZgIImEIOuA2SiKQs36CuKE= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1295905915; x=1295992315; bh=iLDsV7QT5cBP6gMcho7ZG5D3Ig8mIcR85D1gWIWUURE=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=JAxyGcOykJ6iN4mfDn3ZF8W2GFe34ayDKXL9oIW2icDCFTsdNCn49MGoM+Qxv9edV cplCq2y8UIxRN+SUH1CNxU36jvh+eh2lrsK8jyK5tcVWrj0ft1Ah6WoFm3ANhgxC8S pNCm69h/Njn+FDwYiHoneY1/JjaUZrKdm5nZXUrc= DomainKey-Signature: a=rsa-sha1; s=mail; d=resistor.net; c=simple; q=dns; b=OeHvPFXWIK4mFlTMZwlQ6gMI7G/bTJ4Iw1LCZfXblQRuM+D2vClt+fa4ui2vwI3Ry rWjv/XzGt8tNhff0PwEXpfsGvl/N0e0zdh3OYE7YqYr2JHAeBHJ2AIgeW5KiKLO6fvI 3J0RIX1T6Afsd/AVuW6nMl7zPSaTcB288o0K+ZI= Message-Id: <6.2.5.6.2.20110124131217.06ff0fe8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 24 Jan 2011 13:13:58 -0800 To: =JeffH From: SM In-Reply-To: <4D3A2DE2.4050304@KingsMountain.com> References: <4D3A2DE2.4050304@KingsMountain.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: IETF cert-based identity 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: Mon, 24 Jan 2011 21:49:02 -0000 Hi Jeff, At 17:07 21-01-11, =JeffH wrote: >No, "foo*" isn't a legit dns label per se. However, it's only used in >"presented" domain names in various contexts -- certs being one -- >and intended >for matching within applications, not for actual dereferencing via the DNS. Thanks for clarifying that and for the feedback. Regards, -sm