On 2010-07-12 10:22 PDT, Peter Saint-Andre wrote:
> 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?

<dilbert> Gaa! </dilbert>   Let's not open Pandora's box wider!!

One of the big weaknesses of PKI right now is the lack of effective use of
name constraints.  CAs do not constrain the names that their subordinate
CAs may issue.  And one of the big reasons for that is that name constraints
are not defined to apply to DNS names in Subject CNs, so they're ineffective.

Trying to apply DNS name constraints to subject CNs is a can of worms,
because subject CNs may legitimately contain things that are not DNS names
at all.  It's not correct to declare a cert chain invalid because the EE
cert contains CN="Peter Saint-Andre" and also CN="www.stpeter.im" but the
issuer CA is constrained to "*.stpeter.im".  There's no test that 100%
accurately answers the question "Is this string a DNS name or not?", and
so it is not generally possible to answer the question "Should this CN
be subjected to a DNS name constraint or not?".

SANs solve this whole problem.  They have a component that may ONLY contain
DNS names, and therefore is easily constrained.  DNS name constraints would
be effective if certs ONLY put DNS names into SANs.  But putting DNS names
into SANs effectively bypasses name constraints (at least, in
implementations I tested last year).

IMO, we should be attempting to drive a stake in the heart of DNS names in
subject CNs, and moving all CAs to use SANs exclusively for DNS names.

Let's close Pandora's box, not open it wider.