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
_______________________________________________
certid mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/certid
