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

[Kaspar Brand <[e-mail]>]

On 14.07.2010 17:47, Nelson B Bolyard wrote:
> 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.

That's an argument for completely banning CN-IDs, in the first place.
But I fail to see how it is relevant for the decision whether to only
check the "(most specific) Common Name field" or all of the CNs.

> But putting DNS names
> into SANs effectively bypasses name constraints (at least, in
> implementations I tested last year).

Should read "... into CNs", I guess? In any case, if you disregard CNs
in the subject for name matching as soon as there is a subjectAltName
extension with at least one dNSName (as
draft-saintandre-tls-server-id-check-08 does), then it's becoming a
non-issue.

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

-08 already does this in several places:

       The certificate SHOULD NOT represent the server's fully-qualified
       DNS domain name in a CN-ID, even though many deployed clients
       still check for this legacy identifier configuration within
       certificate subjectName. [...]

      Notwithstanding any of the foregoing rules, reference identifiers
      of type CN-ID (if included) MUST always be the lowest-priority
      reference identifiers in the list. [...]

      Security Note: A client MUST NOT seek a match for a reference
      identifier of CN-ID if the presented identifiers include an
      SRV-ID, URI-ID, DNS-ID, or any application-specific subjectAltName
      entry types supported by the client.

I'm doubtful if adding a MUST NOT for CN-IDs (vs. a SHOULD NOT) would
have a considerable impact on future CA practices. Most of them probably
don't want to risk compatibility issues with legacy implementations
(which don't recognize the subjectAltName extension).

Kaspar