Re: [Gen-art] Gen-ART last call review of draft-ietf-mile-rfc6046-bis-05

[Brian Trammell <[e-mail]>]

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
>>>>