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

[Kaspar Brand <[e-mail]>]

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

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

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]

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.

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. (It happens to be the same CA as the one appearing in
the message referenced by Ludwig, for the sake of completeness.)