Re: [certid] CN-ID and name constraints

[Martin Rex <[e-mail]>]

Matt McCutchen wrote:
> 
> Name constraints are designed to support secure delegation of the
> ability to issue certificates for a portion of the namespace.  Why
> wouldn't CAs use them for that purpose?  Just because you said so?

Terminology confusion.

Name constraints do not delegate anything.  They authorize
subordinate CA to issuer certs within specific constraints.
And delegation in DNS is represented by DNS "NS" records
and managed by domain registrars.


> 
> A certificate that violates a name constraint is invalid, and under any
> sane contract or legal system, the superior CA will not be liable to
> anyone who relies on an invalid certificate.

99.999% of TLS server certs are accepted by TLS clients
is absence of contracts between TLS client and issuing CA.

~50% of the installed base of TLS (Windows XP&2003) does not
check vor TLS server cert revocation, although there is probably
no CAs left among those ~100 valid pre-trusted RootCAs that do
not offer CRLs distribution points or OCSP responders.

If there are any relevant contracts involving meaningful liabilities,
it is likely among superior and subordinate CAs.  Even server cert
customers are kept at bay with fancy "Certificate Practice Statements".


> 
> Matching a reference server name against a CN-ID that violates a dNSName
> constraint defeats the purpose of name constraints.  With respect to
> clients willing to do this, a name constraint is a security no-op.

No, it is not.  If there is anything wrong, then it is the
server endpoint identification algorithm that is abusing X.509.

Name Constraints processing, as specified by PKIX, is NONE of the
apps business.  Processing of name constraints is exclusively
the task of the certificate path validation implementation
within the PKI software, and the app doesn't need to know or
care whether and which subtrees were collected while
building the certification path and later processed during
certificate path validation.


> 
> > Go kick the PKIX folks if you don't like how it is spec'ed,
> > but leave the apps folks alone.  I believe that asking the apps
> > folks to regurgitate and re-chew stuff that the PKIX part didn't
> > process to someone's satisfaction is an _extremely_ bad idea.
> 
> server-id-check is built on PKIX, not vice versa, so server-id-check is
> responsible for the security consequences of the CN-ID that it defines
> for the name constraints defined by PKIX.  It has the option to solve
> the problem or say "this breaks the security of name constraints and we
> know it", which would be laughable for a standard.


10 years ago, the use of CN-ID has been deprecated by rfc-2818 and
been specified to not be used when DNSName SAN is present.

It seems like a bad idea to massively increase the complexity
of a long deprecated server identification scheme, and in a
fashion that is not only a magnitude more complex, but
also amounts to a gruesome breach of the PKIX architecture.


I'm sorry for having totally missed the TLS&IETF consenus to abandon
subjectAltNames for server-id-check and to resurrect CN-IDs.


There may not be an API in the PKI software for returning to
the app the hierarchy of dNSName name constraints collected while
composing the cert path and processed during cert path validation,
which the app would need for a seconds constraints check
when it decides to try a CN-ID matching fallback.

If doing DNSName constraints checking proactively during cert path
validation should be allowed, then a REALLY big warning label
would be necessary that CN AVAs must either contain a valid f.q.d.n
or be ABSENT from the server cert subject DName to prevent false
negatives (i.e. name constraints violation errors) in those
new TLS implementations that adopt this fancy logic.

>
> NSS now enforces name constraints on the CN-ID
> (https://bugzilla.mozilla.org/show_bug.cgi?id=394919) and remains
> backward compatible with the web by virtue of the fact that the public
> CAs aren't using name constraints yet.  If the CAs start doing so, all
> an inferior CA has to do for things to work is to include a dNSName SAN,
> which is a SHOULD anyway.


I think it would be more sensible to let CN-IDs rest in peace and
simply skip the CN-ID matching fallback entirely if the CA cert,
which signed the server cert, contains a name constraints extension.


-Martin