Re: [certid] CN-ID and name constraints

[Martin Rex <[e-mail]>]

Matt McCutchen wrote:
> 
> > A CA with name constraints for DNSName SANs (required critical according
> > to rfc5280, mind you) in its own CA certificate that issues TLS server
> > certificates without dNSName SANs yields "fubar" on my scorecard.
> 
> But if by doing that they can issue certificates that clients will
> accept for server names the superior CA did not intend, that's a big
> security problem.

No, there is absolutely no security problem involved.

This is a plain and simple liability issue.  If the superior CA
can not manage the risk appropriately so that the issuing CA will
not do this, then either the superior CA MUST NOT certify that
issuing CA, or the clients MUST NOT trust the superior CA.

It is really as simple as that.

Btw. is it completely ridiculous to put Constraints into
certificates for a resource that is managed aribraritly on a
first-come, first-served basis such as DNS hostnames and
think of it as a security feature.

What some entirely fail to understand is that this is about
a backwards compatibility issue with the installed base,
and no amount of praying, cursing and issuing of new Specs with
MUST NOTs in them will change the behaviour of the installed base
in any way or form.

New specs affect only new stuff (implementations and CAs),
and to a very limited amount patches into the installed base,
under the condition that the change DOES NOT BREAK existing
productive usage scenarios.


NameConstraints are ill-designed to support what some people
intend to do with them.  They're specify to constrain only
name components that are present, not name components that
are absent.

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.


As far as Joe Average User is concerned, which of the CAs shipping
in current Browsers does have the alleged security problem anyway?
The way they're specified, NameConstraints are not a security feature,
but rather a means to enforce a business model, because NameConstraints
can no longer securely if there is more than one trust anchor.
TLS as used on the internet is approaching 100 seperate trust anchors...


> 
> > Those that need the backwards compatibility will _not_ disable
> > the matching fallback if DNSName SANs are present,
> 
> NSS doesn't:
> 
> https://mxr.mozilla.org/mozilla/ident?i=CERT_VerifyCertName
> 
> The idea is that by including a dNSName SAN, the CA opts out of the
> backward compatibility.  I don't think anyone issues certificates with
> both dNSName SAN and CN with the intent that the CN be honored as a
> server name.

Well no, this is another absolute nonsense, because again it
completely ignores the (behaviour of) the installed base.
The only way to opt out of CN-ID matching is to issue server
certs entirely without CN AVAs in the subject name.
Anything else than CN=f.q.d.n or NO CN AVA is non-sensical.

The only problem with CN-less subject names is, that
it might create serious usability issues with a number of
existing certificate maintenance UIs...


> 
> > and they're
> > even more unlikely to adopt such a weird name constraints
> > processing of a fallback they shouldn't be doing in the 
> > first place and keep doing only to not interfere with
> > installed base.
> 
> Those that need backwards compatibility, name constraints, and security
> need to do something about this issue.

I'm not aware of a reasonable justification for the existance
of PolicyConstraints and NameConstraints in certificates other
than governmental agencies and military would like to use it
eventually and still be able to procure on the commodity market.

The situation for ECC crypto is similar.  Although there may
be some usefulness in having alternative algorithm to RSA at some
point in the future when all of the annoying patents have expired.


-Martin