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

[Alexey Melnikov <[e-mail]>]

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