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

[Erwann ABALEA]

2011/5/5 Daniel Veditz <dveditz at mozilla.com>:
> On 4/22/11 4:44 PM, Erwann ABALEA wrote:
>> 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.
>
> The wildcard rules are very clearly spelled out in the standards,

Which standard? X.509 doesn't talk about this, RFC2459/3280/5280
leaves such considerations outside of its scope, RFC2818 covers only
HTTPS and is of "Informational" level, RFC2595, covers TLS with IMAP
and POP3. Both RFCs have a definition of wildcard, but not the same.
RFC6125's purpose is exactly on identity check, and paragraph 7.2
explains that wildcard is not clearly specified at all. Earlier in
this document, wildcard usage is not recommenced.

> but for a long time NSS continued to follow pre-standard historical
> behavior. Initially to avoid breaking customers using that feature
> in Netscape's and later iPlanet's servers, but then far too long
> after that on inertia alone. It's all good now though. What does
> that have to do with NameConstraints?

Evident. NameConstraints is about contraints on names, wildcard is
about representation of several names in a unique form.

-- 
Erwann.