Re: [TLS] RFC 2818 wildcard rationale

[Martin Rex <[e-mail]>]

Chris Richardson wrote:
> 
> > Regarding #1, if * matched multiple labels, it would match
> > www.yourbank.com.whatever.example.com, which would be a very bad thing since
> > it can mislead users into thinking that they are visiting
> > "www.yourbank.com".
> 
> Are there any circumstances under which an (individual/organization)
> is authorized to have a certificate for *.example.com, but is not
> authorized to have a certificate for
> www.yourbank.com.whatever.example.com?

That is an "interesting question" (not on DANE's radar so far).

Being authorized (as being the domain owner) does not mean that every
commercial/public CA will issue a TLS server certificate for such a name.

AFAIK, at least some of the CAs will refuse to issue TLS server certs
to owners of domains that could be used for typo-squatting high-profile
sites/domains.

The issue that Yngve mentioned is about the common behaviour of
DNS resolvers to have a "default domain" or "searchlist" which they
use to complete a hostname that does not have a trailing dot before
trying to resolve that name via DNS.


> 
> > Regarding #2, I don't think that would introduce any real badness, except
> > having to edit the rulestring, which make already complex logic more
> > complex, and more likely to fail an unsecure manner (there is also the fact
> > that you can have "f*.example.com", which should not allow #2 to be
> > generated, causing more complexity). However, adding a separate rule for
> > "example.com" in the SAN field is very simple.
> 
> If both (1) and (2) were allowed, that would eliminate the need for
> wildcards which should simplify the logic.
> 
> And out of curiousity, are there any real examples of f*.example.com
> certificates?  Are there any circumstances under which that is a good
> idea?

There is a huge variety of different behaviour in the installed
base with respect to wildcard matching from rfc2818 Section 3.1
server endpoint identification.

Adding more options at this point would only lead to further divergence
of the behaviour (=less predictable) in the installed base,
so I consider it a bad idea.

Limiting the options to what is easy to understand and explain,
and supported by a significant fraction of the installed base,
seems much more reasonable at this point.


-Martin