[SSL Observatory] Name constraints: a reasonable idea that hasn't panned out in practice

[Erwann ABALEA]

2011/4/23 Chris Palmer <chris at eff.org>:
> [ Jesse Burns told me about the observations I describe in this email, so credit him for the wisdom. Of course, if I describe the situation incorrectly, that is on me, not him. :) After hooting about this on Twitter with Adam Langley and Zooko, Jeff H. suggested I post here. Here goes! ]
>
> Name constraints would be a nice thing to have, right? It would reduce the ability of a (say) Swedish CA to sign a certificate for (say) encrypted.google.com.
>
> http://www.ietf.org/rfc/rfc2459.txt

First, RFC2459 has been obsoleted by RFC3280 in 2002, which was then
obsoleted by RFC5280 in 2008.

* why couldn't a Swedish CA be able to deliver a certificate to
*.google.com? Are american CAs the only ones allowed to deliver
certificates to .com domains? From here, mail.google.com certificate
is signed by Thawte, a south-african company.
* the NameConstraints extension was normalized at least in the 2005
edition of X.509 recommendation, and revised in a 2007 technical
corrigendum. I don't know for the 2008 edition of X.509, I haven't
bought it. But that means either its representation or its meaning has
changed recently (4 years is to be considered recent, for
standardization, as some PKI actors can still come with bad
implementations of OCSP, which was defined in 1999)
* the NameConstraints extension is to be used by a CA to place a
constraint on a sub-CA. It cannot be used on a root CA. If you're
talking of "something similar to NameConstraints but placed at browser
level", then it's not an extension

-- 
Erwann.