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

[Peter Saint-Andre <[e-mail]>]

On 1/24/12 9:59 AM, Alexey Melnikov wrote:
> On 24/01/2012 16:45, Peter Saint-Andre wrote:
>> On 1/24/12 2:25 AM, Brian Trammell wrote:
>>> 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.
>> Brian, first of all, thanks for working with us on this topic. As you
>> can see from the length of RFC 6125 (which didn't start out that big!),
>> there's more complexity here than meets the eye.
>>
>> I think the mix of "NOT RECOMMENDED, MUST be ignored by some, but MAY be
>> used by others" might be a bit confusing to those who implement and
>> deploy RID. Also, RFC 6125 makes a distinction between cert generation
>> and cert checking, which gets obscured by the word "use". Thus I might
>> make the following suggestion:
>>
>>     The inclusion of Common Names (CN-IDs) in certificates identifying
>>     RID systems is NOT RECOMMENDED.  A PKI implementation that
>>     understands DNS-IDs SHOULD ignore CN-IDs when checking server
>>     certificates.
> I thought RFC 6125 has a rule saying that CN-IDs are ignored in presence
> of DNS-IDs? I would just rather reference RFC 6125, or at least be clear
> that this is defined there (using "as specified in RFC 6125").

Yes, so you're right: just reference the rules from RFC 6125.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/