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

[Nelson B Bolyard <[e-mail]>]

On 2010/07/14 22:07 PDT, Kaspar Brand wrote:
> 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.

See my argument below.

>> But putting DNS names into SANs effectively bypasses name
>> constraints (at least, in implementations I tested last year).
> 
> Should read "... into CNs", I guess?

Yes, sorry.

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

Yes, but as I read it, people here are proposing to open the spec to say
that multiple CN-IDs are just as acceptable as multiple DNS names in a
SAN.  Frankly, IMO, that will kill SANs and name constraints too.

SANs are having enough trouble getting off the ground.  FAR too many
people still think that CN-IDs are *THE* standard, and are utterly
unaware of SANs.  If we raise multiple CN-IDs to a status they did not
enjoy with RFC 2818, then there will remain no motivation to use SANs at
all, and constraints will die.

Today, the ONE motivation to use SANs is to get multiple DNS names into
a cert.  And that brings with it the hope of constraints.  Take away
that sole motivation, and constraints die.

Sorry, I'm repeating myself.  This constraints issue is very important.

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

Can you name any browser or other important network client made in the
last 8 years (since RFC 3280 was published) that does SSL3 and/or TLS
but doesn't recognize DNS names in SANs?

Best Regards,
/Nelson