[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>:
> On Apr 22, 2011, at 3:19 PM, Erwann ABALEA wrote:
>
>> First, RFC2459 has been obsoleted by RFC3280 in 2002, which was then
>> obsoleted by RFC5280 in 2008.
>
> http://www.ietf.org/rfc/rfc5280.txt
> 4.2.1.10.  Name Constraints
[...]

Yes, I know that NameConstraints extension has not been deprecated.
But the paragraph has changed in the different revisions
(2459/3280/5280).

My intention was to tell that referring to a 1999 RFC that was
obsoleted twice is not a good idea. No offense intended, here.

> So it's still wrong to not mark the extension as critical.

And a CA still can deliver X.509 certificates, without any obligation
to be compliant to RFC5280. RFC5280 is a profile of X.509, it doesn't
replace it, it only gives stricter rules, by restricting possible
choices. The base is still X.509, an ITU standard.
You are right in a sense, as placing a constraint while giving a
verifier the possibility to not enforce it is a nonsense. But look at
BasicConstraints extension in the RFC5280, it is clearly told that
this extension MAY be critical for end-user certificates, giving the
verifier the possibility to ignore this extension, and use an end-user
certificate as a CA certificate. Another nonsense. The X.509 text is
more logical, if you want to have a look at it (the 2005 edition is
free).

>> * why couldn't a Swedish CA be able to deliver a certificate to
>> *.google.com?
>
> Perhaps because Google is a US company. Similarly, perhaps we should expect certificates for names in google.se to be signed by a Swedish CA.

So, following this point, a Swedish company couldn't register a domain
name in anything other than .se TLD, or shouldn't be able to get a
certificate for its domain? Or ... wait ... Google.se can be signed by
a Swedish CA, even if Google is still american? (BTW, just perform a
whois lookup for google.se, and try to link the result to Google).

> I don't know what a good policy for name constraints would be. But definitely people have proposed it and/or some mechanism like it as a way to cope with the otherwise unconstrained authority of CAs

NameConstraints extension exists, but it can be useful only in a
limited environment, not on the Internet. Given the number of .com
domains, how could one possibly list all the "non swedish" ones among
them, and place them in the "excluded subtree" of a Swedish CA? (a TLS
record is only 16k long, so you can't transfer an object larger than
that, a certificate can't be split in several records).

>> 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.
>
> Well, VeriSign, an American company and the .com registrar, bought Thawte. But obviously you are right. I did not and would not suggest that only an American CA be able to sign .com names.

(I worked indirectly for Verisign when they bought Thawte)
That doesn't mean Thawte became an american company. VeriSign (the
part that existed before they bought NetworkSolutions) has later been
bought by Symantec. Who knows if Symantec won't be bought tomorrow by
a Japanese company? Sould all the certificates be revoked then, and
every "exluded subtrees" be changed to reflect this new state?

>> * 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)
>
> Well, as you say, "RFC2459 has been obsoleted by RFC3280 in 2002". So the idea is at least nine years old.

I guess the first edition of X.509v3  (in 1997) already had this
extension, but I don't have my copy right here.

My point was that this extension has changed, 4 years ago, so
expecting a proper implementation by every browser is not something to
happen tomorrow. After all , some people are still using IE6.

> According to Wikipedia, "On June 12, 2007, the CA/Browser Forum officially ratified the first version of the Extended Validation (EV) SSL Guidelines, which took effect immediately." So ideas younger than name constraints have been widely and well implemented already. Maybe nobody really wants name constraints, or maybe there is some technical or other limitation in the idea as currently specified. Maybe we could rectify that.

What EV has to do with NameConstraints? Nothing.

> I'm just throwing out data points from the Observatory. I have no particular bias for or against the idea of name constraints.

That point was raised in the Mozilla Policy usenet group a few
months/years ago, with no consensus. Good idea in theory, but
absolutely non practical.

-- 
Erwann.