Hi, Alexey, So far only one voice on the WG list, stating no need for CN-ID. However, on thinking about it a bit further, if you happen to have an older PKI built out, and you're still using it, you've probably got a large investment in it, and it probably makes sense to allow you to use it for RID too...
So, I'd suggest the following language to grudgingly allow such a thing: The use of CN-ID identifiers in certificates identifying RID systems is NOT RECOMMENDED, and CN-ID identifiers MUST be ignored by PKI implementations which can use DNS-ID identifiers. However, CN-ID identifiers MAY be used when the RID consortium to which the system belongs uses an older, existing PKI implementation. Thoughts? Thanks for all your help, and cheers, Brian On Jan 23, 2012, at 5:17 PM, Alexey Melnikov wrote: > On 23/01/2012 16:12, Brian Trammell wrote: >> Hi, Alexey, > Hi Brian, >> I can take the CN-ID question to the MILE WG on this. > Sounds like a good idea. >> In any case, is it clear enough from this language that CN-ID is a >> "compatibility-only" feature? > I think your text is clear enough. >> >> Cheers, >> >> Brian >> >> On Jan 23, 2012, at 4:32 PM, Alexey Melnikov wrote: >> >>> On 23/01/2012 14:22, Brian Trammell wrote: >>>> Hi, Alexey, >>> Hi Brian, >>>> one more round (hopefully) :) ... >>>> >>>> On Jan 23, 2012, at 2:19 PM, Alexey Melnikov wrote: >>>> >>>>>> Okay; how about the following (including Alexey's comments from the >>>>>> previous review, and pointing more specifically to 6125) >>>>>> >>>>>> <t>RID systems MUST verify the identity of their peers against that >>>>>> stored >>>>>> in the certificate presented, as in section 6 of<xref >>>>>> target="rfc6125"/>. >>>>>> As RID systems are identified not by URI and RID does not use DNS SRV >>>>>> records, they are identified solely by their DNS Domain Names; see >>>>>> Section >>>>>> 6.4 of<xref target="rfc6125"/>. >>>>> (I think you are saying that [using RFC 6125 terminology] DNS-IDs are >>>>> supported, but SRV-IDs or URI-IDs aren't.) >>>> I can say that directly then. >>> That would be good, thanks. >>> >>>>> This is better, but I think you need to say a bit more. Are CN-IDs >>>>> allowed? Are wildcards allowed? >>>> Here, I'm a little unclear on the implications this has for >>>> implementation: is it reasonable to assume that all implementations that >>>> support TLS 1.1 should not require CN-IDs for backward compatibility? >>> There is no direct correlation. But you should keep away from CN-IDs in new >>> protocols, if you can. RFC 6125 goes into details why CN-ID don't >>> necessarily work. >>> In reality though, you might have to support CN-IDs if you are using >>> existing Certificate Authorities, as opposed to creating your own ones. >>> >>>>> Another example of the document that describes >>>>> http://tools.ietf.org/html/draft-melnikov-email-tls-certs-00 >>>> Thanks for the example. Here's what I've come up with for now... >>>> >>>> <t>RID systems MUST verify the identity of their peers against that >>>> stored >>>> in the certificate presented. All RID systems MUST be identified by a >>>> certificate containing a<xref target="RFC5280">DNS-ID identifier</xref> >>>> as in section 6.4 of<xref target="RFC6125"/>. Certificates identifying >>>> RID systems MAY additionally contain a CN-ID identifier, to allow >>>> backward >>>> compatibility with older PKI implementations. Wildcards MUST NOT >>>> appear in >>>> the DNS-ID or CN-ID of a certificate identifying a RID system. >>>> Additional >>>> general information on the use of PKI with RID systems is detailed in >>>> Section 9.3 of<xref target="I-D.ietf-mile-rfc6045-bis"/>.</t> >>>> >>>> (The text about CN-IDs would be removed if the assumption that TLS 1.1 >>>> implies no need for CN-ID, as above) >>> This looks Ok (with or without CN-ID). I am a bit undecided about CN-ID. >>>> Thanks, >>>> >>>> Brian >>>> _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
