Comment 9 for bug 376484

(In reply to comment #6)
> b) (as reported in comment 0), NSS matches a "*" to any characters,
> whereas RFC 2818 suggests it should not match a ".". We do this for
> backwards compatibility with NSS's original spec on pattern matching.

Count me in as another (strong) proponent of changing this - for two reasons:

1) most other implementations I've encountered so far (MSIE/Schannel,
   Opera, Safari/libsecurity_apple_x509_tp, Konqueror/KDE, GnuTLS)
   apply a more restrictive matching than NSS (although they differ in
   their specific behavior, but at least they do not allow using certs
   with subjects like CN=*)

2) there are at least two other RFCs (besides 2818) which stipulate the more
   restrictive form of wildcard matching, and these are actually on the
   "Standards Track":

   a) RFC 2595 ("Using TLS with IMAP, POP3 and ACAP", June 1999) says
      in 2.4., "Server Identity Check":

      - 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.

   b) RFC 4513 ("Lightweight Directory Access Protocol (LDAP):
      Authentication Methods and Security Mechanisms", June 2006) states
      under 3.1.3.1., "Comparison of DNS Names":

      The '*' (ASCII 42) wildcard character is allowed in subjectAltName
      values of type dNSName, and then only as the left-most (least
      significant) DNS label in that value. This wildcard matches any
      left-most DNS label in the server name. That is, the subject
      *.example.com matches the server names a.example.com and
      b.example.com, but does not match example.com or a.b.example.com.