Re: patch SSL certificate warning

On Fri, Sep 07, 2007 at 09:35:32AM +1200, Matt Bodley wrote:
> It is widely accepted that *.domain.com means xxx.domain.com, but not so
> clear that this also means yyy.xxx.domain.com, but in my view, this is the
> same as it follows DNS delegation in both instances (of the implied/inherent
> trust that is dictated by DNS).
>

RFC 2595 (which deals with TLS for IMAP and POP3, and was, I believe one
of the first RFCs to deal with wildcards) simply reads (in 2.4):

     - A "*" wildcard character MAY be used as the left-most name
     component in the certificate. For example, *.example.com would
     match a.example.com, foo.example.com, etc. but would not match
     example.com.

So that's not clear either way. RFC 2818 (which deals with TLS for
HTTP) reads (in 3.1):

   ... Names may contain the wildcard
   character * which is considered to match any single domain name
   component or component fragment. E.g., *.a.com matches foo.a.com but
   not bar.foo.a.com. f*.com matches foo.com but not bar.com.

Which is pretty clear as _not_ allowing this behaviour. I understand
that RFC 4513 also mandates this approach for LDAP.

It also appears that the current Firefox behaviour is considered a bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=159483

So, while it _might_ arguably make things more complex to keep with the
current behaviour (but perhaps no more than the widely-understood case
where a certificate for *.example.com doesn't match http://example.com),
it seems like it would be a mistake to make a change away from the
current RFC-compliant behaviour.

Regards,
Malcolm