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

Erwann ABALEA erwann at abalea.com
Fri Apr 22 16:44:09 PDT 2011


2011/4/23 =JeffH <Jeff.Hodges at kingsmountain.com>:
>>> * why couldn't a Swedish CA be able to deliver a certificate to
>>> *.google.com?
>
> well, I think what Chris was really imagining is mis-issuance of certs, for
> (well-known) entities that already have certs, to bad actors who then want
> to
> MITM users of said entities.

I understood his intention like this, and was only trying to explain
that NameConstraints extension is really not the good way to solve
this.
DANE (or similar), on the contrary, can be a good solution, for DV
certificates. Obviously DV certs are still selling well, so DANE has
some future. Unfortunately for my employer, because it could allow
anybody to have its own CA, and produce its own certificates, and they
won't produce any warning, and they'll probably be produced with awful
practices. Classic human behavior, but still bad :)

[...]

> there were a couple of longish threads wrt Name Constraints (and related
> cert naming issues) recently (in IETF-time) on the certid@ list that may be
> illustrative of the mess of issues involved here...
[...]
> ..whose length and complexity should inform the reader about how
> gnarly/unwieldy all this PKIX/X.509 stuff is.

NameConstraints is not mature enough to be of any use.
Identity verification when receiving a certificate is really a mess,
as it's not covered at all neither in X.509 nor in RFC2459/3280/5280,
as it's dependent on the protocol/application using the cert. Wildcard
certificates were verified with different rules wether IE/CAPI or
FF/NSS was used, if memory serves right; I think FF/NSS considered
that something like "*.domain.com" could match
"very.secure.domain.com", for example, but IE didn't. Lack of
standardization.

-- 
Erwann.



More information about the Observatory mailing list