Ubuntu
firefox-3.0 package

  1. Bug #376484
  2. Comment #26

Comment 26 for bug 376484

Revision history for this message
In , Mozbugzilla (mozbugzilla) wrote :

(In reply to comment #25)
> Having said that, it does seem that wildcard patterns with stars in the
> top two levels of domain (such as "*" and "*.com") are undesirable.

When modifying the "*" to no longer match a ".", CN=* could still make some sense for Intranet URLs (such as "https://webmail"). I'm not opposed to this drop this option as well, but others might complain vociferously if we do so.

> I would be willing to impose a new restriction, that wildcards must be
> followed by at least two dots (that is, two domains) excluding a trailing
> dot, which I do not propose to ignore (in concurrence with comment 21).

Would you want to support patterns like www.*.example.com? It's true that RFC 2818 doesn't disallow such patterns (since it doesn't require the wildcard character to occur in the left-most component only), but given a number of other recent TLS related RFCs and Internet drafts, my impression is that the current consensus is to allow the in the first component only:

- RFC 4642 (October 2006), TLS with NNTP
- RFC 4954 (July 2007), STARTTLS SMTP extension
- draft-ietf-nsis-ntlp-14 (July 2007), General Internet Signalling Transport
- draft-badra-tls-netconf-04 (Oct. 2007), NETCONF over TLS

All these basically use the wording from RFC 2595 ("MAY be used as the left-most name component in the certificate"), so if RFC 2818 - from May 2000 - would be written today, my guess is that we'd see the same wording there, too.

Only allowing the "*" in the first component is also in line with the behavior implemented by Microsoft's Schannel library since Windows 2000 SP1 (see http://support.microsoft.com/kb/258858 - note that some of the "accepted wildcard examples" are completely wrong; the text description is accurate, however).

Therefore I still suggest going for the solution outlined in comment 22 (possibly with dropping support for "dotless" names). It's both in line with the RFCs and with the behavior of a very widespread implementation of another vendor, so chances are pretty small that this will "break the Net"...

What solution does the NSS team favor? Thanks for additional comments/opinions.