http://blog.gmane.org/gmane.ietf.certid hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://comments.gmane.org/gmane.ietf.certid/577 <pre>FYI. -------- Original Message -------- Subject: RFC 6125 on Representation and Verification of Domain-Based Application Service Identity within Internet Public KeyInfrastructure Using X.509 (PKIX) Certificates in the Contextof Transport Layer Security (TLS) Date: Wed, 30 Mar 2011 15:33:53 -0700 (PDT) From: rfc-editor-i4YTrOVFbXmRpAAqCnN02g&lt; at &gt;public.gmane.org To: ietf-announce-EgrivxUAwEY&lt; at &gt;public.gmane.org, rfc-dist-i4YTrOVFbXmRpAAqCnN02g&lt; at &gt;public.gmane.org CC: rfc-editor-i4YTrOVFbXmRpAAqCnN02g&lt; at &gt;public.gmane.org A new Request for Comments is now available in online RFC libraries. RFC 6125 Title: Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS) Author: P. Saint-Andre, J. Hodges Status: Standards Track Stream: IETF Da</pre> Peter Saint-Andre 2011-03-30T22:51:22 http://comments.gmane.org/gmane.ietf.certid/563 <pre>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 WG). Thanks to everyone who contributed to and provided feedback on this document -- your input is very much appreciated! Peter </pre> Peter Saint-Andre 2011-01-21T02:20:57 http://comments.gmane.org/gmane.ietf.certid/557 <pre>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? </pre> Matt McCutchen 2011-01-17T19:13:04 http://comments.gmane.org/gmane.ietf.certid/556 <pre>FYI. ----- Original Message ----- From: Lars Eggert &lt;lars.eggert-xNZwKgViW5gAvxtiuMwx3w&lt; at &gt;public.gmane.org&gt; To: The IESG &lt;iesg-EgrivxUAwEY&lt; at &gt;public.gmane.org&gt; Cc: kurt.zeilenga-XZk+60lJk0kAvxtiuMwx3w&lt; at &gt;public.gmane.org &lt;kurt.zeilenga-XZk+60lJk0kAvxtiuMwx3w&lt; at &gt;public.gmane.org&gt;; Jeff.Hodges-4oNgW8ERKvixQugyqXuc6AC/G2K4zDHf&lt; at &gt;public.gmane.org &lt;Jeff.Hodges-4oNgW8ERKvixQugyqXuc6AC/G2K4zDHf&lt; at &gt;public.gmane.org&gt;; psaintan-FYB4Gu1CFyUAvxtiuMwx3w&lt; at &gt;public.gmane.org &lt;psaintan-FYB4Gu1CFyUAvxtiuMwx3w&lt; at &gt;public.gmane.org&gt;; draft-saintandre-tls-server-id-check-nZLwadvX8BDR74oF6e/6QQ&lt; at &gt;public.gmane.org &lt;draft-saintandre-tls-server-id-check-nZLwadvX8BDR74oF6e/6QQ&lt; at &gt;public.gmane.org&gt; 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</pre> Peter Saint Andre 2011-01-17T16:24:14 http://comments.gmane.org/gmane.ietf.certid/555 <pre>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 </pre> =JeffH 2011-01-17T15:21:26 http://comments.gmane.org/gmane.ietf.certid/554 <pre>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=draft-saintandre-tls-server-id-check-14 This document is on the agenda for the next Thursday's IESG telechat. Peter </pre> Peter Saint-Andre 2011-01-13T00:31:35 http://comments.gmane.org/gmane.ietf.certid/549 <pre> 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 </pre> Cullen Jennings 2010-12-16T14:29:11 http://comments.gmane.org/gmane.ietf.certid/548 <pre>Jeff and I have published version -12. The changes were driven by the Gen-ART review that Ben Campbell did, some feedback from our sponsoring Area Director, a few list discussions, and several rounds of editorial improvement. http://www.ietf.org/id/draft-saintandre-tls-server-id-check-12.txt The diff from -11 is here: http://tools.ietf.org/rfcdiff?url2=draft-saintandre-tls-server-id-check-12.txt Thanks! Peter </pre> Peter Saint-Andre 2010-12-13T19:49:49 http://comments.gmane.org/gmane.ietf.certid/520 <pre>Subject: Re: Second Last Call: draft-saintandre-tls-server-id-check (Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)) to BCP From: SM &lt;sm-6ilGXZ639oLk1uMJSBkQmQ&lt; at &gt;public.gmane.org&gt; Date: Tue, 07 Dec 2010 13:36:43 -0800 To: ietf-EgrivxUAwEY&lt; at &gt;public.gmane.org Cc: Peter Saint-Andre &lt;psaintan-FYB4Gu1CFyUAvxtiuMwx3w&lt; at &gt;public.gmane.org&gt;, Jeff Hodges &lt;Jeff.Hodges-H+UqYreoeRnQT0dZR+AlfA&lt; at &gt;public.gmane.org&gt; At 04:36 18-11-10, The IESG wrote: &gt;The IESG has received a request from an individual submitter to consider &gt;the following document: &gt; &gt;- 'Representation and Verification of Domain-Based Application Service &gt; Identity within Internet Public Key Infrastructure Using X.509 (PKIX) &gt; Certificates in the Context of Transport Layer Security (TLS) ' &gt; &lt;draft-saintandre-tls-server-id-check-11.txt&gt; as a BCP &gt; &gt;The IESG plans to make a decision in the next f</pre> =JeffH 2010-12-08T18:02:53 http://comments.gmane.org/gmane.ietf.certid/505 <pre>This might be of interest regarding re-use of the server-id-check document... /psa -------- Original Message -------- Subject: Re: Peter Saint-Andre's DISCUSS on draft-igoe-secsh-x509v3-06 Date: Tue, 07 Dec 2010 08:22:25 -0700 From: Peter Saint-Andre &lt;stpeter-LREDBpT6QYzArPYJPGU0mg&lt; at &gt;public.gmane.org&gt; To: Douglas Stebila &lt;douglas-Q8nIND0s1Pmw5LPnMra/2Q&lt; at &gt;public.gmane.org&gt; CC: =JeffH &lt;Jeff.Hodges-1XFhAeWrR4GxQugyqXuc6AC/G2K4zDHf&lt; at &gt;public.gmane.org&gt;, draft-igoe-secsh-x509v3-nZLwadvX8BDR74oF6e/6QQ&lt; at &gt;public.gmane.org, The IESG &lt;iesg-EgrivxUAwEY&lt; at &gt;public.gmane.org&gt;, kmigoe-JXiH2Qp+pBI&lt; at &gt;public.gmane.org, jhutz-D+Gtc/HYRWM&lt; at &gt;public.gmane.org That's helpful regarding certificate issuance, but it doesn't say how the client is to perform comparisons. As you can see from the I-D I pointed you to, there are subtleties involved, such as internationalized domain names (IDNs) and so-called wildcard certificates (e.g., *.example.com). I didn't know the topic could be so interesting until I took over editorship of that document. :) </pre> Peter Saint-Andre 2010-12-07T15:30:51 http://comments.gmane.org/gmane.ietf.certid/502 <pre>The EFF (TLS/)SSL Observatory data is available via links to .torrent files here.. https://www.eff.org/observatory the 3 files all together take ~13gb of space compressed. I haven't yet poked through them so don't know what it'll be when unpacked. =JeffH </pre> =JeffH 2010-12-07T01:05:57 http://comments.gmane.org/gmane.ietf.certid/499 <pre>I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at &lt;http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq&gt;. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-saintandre-tls-server-id-check-11 Reviewer: Ben Campbell Review Date: 2010-12-03 IETF LC End Date: 2010-12-16 Summary: This draft is almost ready for publication as a BCP. I have a few questions and comments that I think should be considered first, as well as a few editorial comments. *** Major issues: </pre> Ben Campbell 2010-12-06T17:19:30 http://comments.gmane.org/gmane.ietf.certid/484 <pre>draft-saintandre-tls-server-id-check-11, section 3.2 says: A certificate for the IMAP-accessible email server at "mail.example.net" might include SRV-IDs of "_imap.mail.example.net" and "_imaps.mail.example.net" (see [EMAIL-SRV]) and a DNS-ID of "mail.example.net". As I understand it, the SRV-ID is based on the source domain, not the derived domain, and so "_imap.mail.example.net" would only be correct if you were expecting clients to do a SRV lookup for "_imap._tcp.mail.example.net". But the more usual case would be doing a lookup for "_imap._tcp.example.net", in which case the corresponding SRV-ID would "_imap.example.net". Right? So the example should say something like A certificate for the IMAP-accessible email server at "mail.example.net", which is pointed to by the SRV records "_imap._tcp.example.net" and "_imaps._tcp.example.net", might include SRV-IDs of "_imap.example.net" and "_imaps.example.net" (see [EMAIL-SRV]) and a DNS-ID of "mail.example.net". Likewise for the</pre> Dan Winship 2010-11-20T21:28:11 http://comments.gmane.org/gmane.ietf.certid/483 <pre>Being quite offtopic here, i still do not know a more appropriate discussion group. We are all aware that SSL does *not* actually use full x503v3 capabilities to build sane trust hierarchy. We have a "cardhouse" instead, while one flawed CA may ruin the whole system. Well, i did not consider that to be a fatal treat until i got aware of these things, just a matter of close future, despite the fact we have CAs closely affiliated with domestic and foreign ;-) (wherever point of view we take) government organizations, just some random privately owned companies, known malicious entities (like Etisalat), etc etc. There was a way to fix it: once a CA shows any malicious activity, it gets kicked out, revoked and forgotten. Now let's face it: http://www.narus.com/index.php/news/industry-news/article/209 old news, 2005, but the partnership is scary. What if not only Narus offers services to Versign, but vice versa as well? We cannot just "kick Verisign out", "all our base belong to them". There is *no place* for</pre> ArkanoiD 2010-11-20T21:27:04 http://comments.gmane.org/gmane.ietf.certid/482 <pre>Jeff and I just posted version -11 of the server-id-check spec, based on list feedback from Jim Schaad and Eddy Nigg, discussions at IETF 79 last week, and a further review by our sponsoring AD. The diff is here: http://tools.ietf.org/rfcdiff?url2=draft-saintandre-tls-server-id-check-11 Next we expect that Alexey will issue a second IETF Last Call on this I-D, given the substantive changes since -09 and the fact that the first Last Call labelled the intended state of the spec as Proposed Standard, not Best Current Practice. Thanks for your continued attention to this work. Peter </pre> Peter Saint-Andre 2010-11-18T01:19:53 http://comments.gmane.org/gmane.ietf.certid/460 <pre>So what are our next formal steps for -tls-server-id-check ? thanks, =JeffH </pre> =JeffH 2010-10-20T17:08:04 http://comments.gmane.org/gmane.ietf.certid/459 <pre>Finally! The diff is here: http://tools.ietf.org/rfcdiff?url2=draft-saintandre-tls-server-id-check-10 -------- Original Message -------- Subject: I-D Action:draft-saintandre-tls-server-id-check-10.txt Date: Wed, 20 Oct 2010 09:30:02 -0700 (PDT) From: Internet-Drafts-EgrivxUAwEY&lt; at &gt;public.gmane.org Reply-To: internet-drafts-EgrivxUAwEY&lt; at &gt;public.gmane.org To: i-d-announce-EgrivxUAwEY&lt; at &gt;public.gmane.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS) Author(s) : P. Saint-Andre, J. Hodges Filename : draft-saintandre-tls-server-id-check-10.txt Pages : 46 Date : 2010-10-20 Many application technologies enable a secure connection between two entities by means of Internet Public Key Infrastructure Using X.509 (PKIX) certificates in th</pre> Peter Saint-Andre 2010-10-20T16:36:05 http://comments.gmane.org/gmane.ietf.certid/455 <pre>So, I got a couple of bug reports on my original msg in this thread (thanks!). It turns out (a) my regex was sorta broken, and (b) the subjectCommonName column Ivan has in the dbase table has all the "CN" attr values smooshed into it. So the certs with a subject with just one CN attr-value-assertion (AVA) will (likely) have a reasonable-looking value (but not necessarily a domain name) in the subjectCommonName column, but a subject with multiple CN AVAs will have an odd-looking value in subjectCommonName (like the ones I included in my orig msg). Now, as Martin pointed out, the ones that look like this.. www.cebbank.com+2.5.4.5=#130f313030303030303030303131373438 ..seem to be an RDName that's comprised of two AVAs, and in the/this DN string representation, they're conjoined by a "+" char. And yes, as Matt noted, it seems there's a bug in the parser used for the survey where it apparently assumed that an RDN beginning with a "CN=" contains only a CN AVA. Also, upon examining subject names m</pre> =JeffH 2010-10-19T00:09:45 http://comments.gmane.org/gmane.ietf.certid/452 <pre> &gt;&gt; all 867361 have a "CN=" in the subject name (CN-ID). &gt; &gt; I'd be curious how many have Common Names that are intended to be DNS &gt; domain names like "www.example.com" and how many have plain old names &gt; like "Example Systems, Inc.". Ok, I extracted all CN-IDs (subjectCommonName) in SSL Labs Survey Data, hacked up a regex, wrapped it with some perl, and found there's 1151 "weird" CN-ID values in the data ( 0.13% ). These are string values that don't match a regex describing a optional-whitespace-wrapped LDH (Letter-Digit-Hyphen) domain name (note that an IDN won't match this (one's included below)). Some examples highlighting the variety of types I observe when browsing the "weird" CN-ID values are below. Note that I didn't try verifying this data (eg by checking that the subjectCommonName column matched the CN attributes value in the subject column in the dbase table, nor by going and querying the servers and verifying the cert returned matches the dbase entries). =JeffH ALL IN ONE servi</pre> =JeffH 2010-10-17T04:40:44 http://comments.gmane.org/gmane.ietf.certid/460 <pre>So what are our next formal steps for -tls-server-id-check ? thanks, =JeffH </pre> =JeffH 2010-10-20T17:08:04 http://comments.gmane.org/gmane.ietf.certid/459 <pre>_______________________________________________ certid mailing list certid-EgrivxUAwEY&lt; at &gt;public.gmane.org https://www.ietf.org/mailman/listinfo/certid </pre> Peter Saint-Andre 2010-10-20T16:36:05 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.ietf.certid