Comment 0 for bug 376484

RFC 2818 and 2459 give the rules for cert name matching between an https
(SSL) server cert and the hostname present in the sought URI.

NSS's function CERT_VerifyCertName, which does the server cert name matching,
has its own rules, rules that declare some name matches in circumstances
where the RFCs would not. Changing function CERT_VerifyCertName to follow
the RFCs exactly will break backwards compatibility. It is possible that
some customers (users of mozilla and/or netscape browsers) depend on the
behavior that would be changed/removed if function CERT_VerifyCertName
followed the RFC exactly. So, a decision needs to be made about what rules
function CERT_VerifyCertName will follow in the future.

The scope of this bug is limited to the matching of the URI hostname to
any of the names found in the cert. The fact that function CERT_VerifyCertName
does not presently examine Subject Alternative Names is the subject of bug
103752, and is outside the scope of this bug. When bug 103752 is fixed,
function CERT_VerifyCertName will examine each of the Subject Alternative
Names as well as the Subject name's common name and compare them to the URI
name. At issue in this bug are the rules used in each of those comparisons.

Here is how function CERT_VerifyCertName compares the hostname in the URI
(call it "hn") and the host name from the cert (call it "cn"):

Step 1. If hn does not contain a "dot", and cn does contain a dot, then
        truncate cn at the left most dot.

        e.g. if hn is "www" and cn is "www.foo.com", truncate cn to be "www".

Step 2. If "cn" is a regular expression (e.g. has wild card characters,
         etc.) then test whether hn matches the regular expression in cn.
         If so, the cert name matches, if not it is a mismatch error.
         Either way, Stop here if cn is a regular expression.

Step 3. "cn" is not a regular expression. compare the hn and cn strings.
        if they match, the cert name matches, stop.

Step 4. If hn contained a dot, compare the string to the right of the
        leftmost dot in hn (that is, the domain part of hn) with the
        string cn. If they match, the cert name is considered a match, stop.

        examples:
         if hn is "www.foo.bar" and cn is "foo.bar", they will match.
         if hn is "www.xxx.foo.bar" and cn is "foo.bar", they will not match.

Step 5. The cert name is a mismatch. stop.

Of these, steps 1 and 4 are behavior that would cease if the function was
made to follow the RFC.

Step 1 is done essentially to permit the use of non fully qualified domain
names in https links in intranet environments where there is often
a great desire to omit the common and constant domain portion from URLs.
E.g. employees often want to be able to type in https://mail/ instead of
https://mail.my.company.domain.com/ and step 1 permits this to work.

Many companies have historically wanted to avoid the cost and administrative
burden of getting a separate cert for every machine. They wanted a single
cert & private key that could be used on multiple intranet servers.
Some popular CAs refuse to issue certs with wildcard characters, so step 4
provides an alternative way for a company to get a cert that is valid for all
servers in a domain (but not for servers in subdomains of that domain).

It is unknown how many companies (if any) presently depend on the features
of step 1 and step 4. Assuming that no other browser supports those rules,
and that no companies use any one brand of browser exclusively, it may be
painless to remove those steps.

Your comments are invited.