Re: [certid] Need to define "most specific RDN"

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

On 7/7/10 12:41 AM, Kaspar Brand wrote:
> On 06.07.2010 18:42, Peter Sylvester wrote:
>> X.500 defines a tree structure, the nodes are relative names put
>> into a hierarchie represented by a DN. a prefix of the elements in
>> the sequence defines thus a "subtree", and the relative name of a leaf
>> is the rightmost element, In a tree the most specific element a leaf
>> and moving backwards defined less specific.
>>
>> There is no need at all to talk about binary encoding, or DER or
>> whatever. A DN is a sequence of relative names forming a tree
>> structure when interpreted in the X.500 context. This is thus
>> one clear interpretation of 'most specific'  (for a RDN).
> 
> I don't think that this is the issue here - it's the wording in RFC 2818
> which is the source of all this... well, I'd say, mess:
> 
>    If a subjectAltName extension of type dNSName is present, that MUST
>    be used as the identity. Otherwise, the (most specific) Common Name
>    field in the Subject field of the certificate MUST be used. Although
>    the use of the Common Name is existing practice, it is deprecated and
>    Certification Authorities are encouraged to use the dNSName instead.
> 
>    Matching is performed using the matching rules specified by
>    [RFC2459].  If more than one identity of a given type is present in
>    the certificate (e.g., more than one dNSName name, a match in any one
>    of the set is considered acceptable.)
> 
> Reading "(most specific) Common Name field" as "Common Name in the most
> specific RDN" is one interpretation, but I'm not sure if it's the only
> one. And given the attention this issue received on the list so far, it
> also seems somewhat ironic that this "requirement" is only appearing in
> parentheses in an RFC which happens to be informational only, BTW...

Is there a good security reason for this "requirement"? I don't see one.

>> Anyway, since there is no good reason not to put a subjectAltName,
>> I do not think that one shouls say anything more than
>> "If you use a Common Name other than in the most simple case one
>>   may run a risk not to be interpreted correctly."
> 
> A BCP document should say more that just state how implementations
> currently behave, I think [1].

For sure.

> Leaving that "most specific", peculiar requirement from RFC 2818 aside,
> I don't believe that there are really strong arguments against treating
> multiple CNs in the subject different from a subjectAltName extension
> with multiple dNSName entries - why not consider "a match in any one of
> the set[s]" acceptable...? [2]

That seems eminently sensible to me. (Whether any given CA would issue
such a certificate is a matter of CA policy...)

> Clarifying/fixing that blurry "(most specific)" statement from RFC 2818
> would be highly desirable for the new BCP, IMO. If by this we can get
> away with a term whose meaning isn't intuitively clear (compare this
> e.g. to "left-most DNS label"), then I would definitely consider that a
> plus.

Would removing all mention of "(most specific)" qualify as clarification?

> Kaspar
> 
> 
> [1] From RFC 2026: a BCP document
>    [...] is a vehicle by which the IETF
>    community can define and ratify the community's best current thinking
>    on a statement of principle or on what is believed to be the best way
>    to perform some operations or IETF process function."
> 
> [2] I'm aware of Nelson's message at
> http://www.ietf.org/mail-archive/web/certid/current/msg00115.html, but
> am wondering to how many CAs the statement about unvetted CNs really
> applies. In my sample from 2009, the multi-CN certs (211 out of ~90,000)
> are basically limited to one of the so-called "commercial CAs", and I'm
> pretty sure that this CA does (/claims to) vet all CNs... what they
> actually do is mirror the entries from the subjectAltName extension in
> the subject DN. 

Yes, I think that's what is happening in the example cited.

Peter

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