Re: [certid] open issue: wildcards in component fragments

[Martin Rex <[e-mail]>]

Peter Saint-Andre wrote:
> 
> > http://blog.johnath.com/2009/01/21/ssl-information-wants-to-be-free/
> > 
> > - 382860 total sites (hostnames) returned a cert
> > - 94438 of total sites used a wildcard cert (24%)
> > - 5% of total sites use the wildcard cert with CN=*.blogger.com
> >    ... other blogging/mass-hosting sites similarly high usage
> > 
> > Only a handful (5) use the "f*.example.com" form; all those were certs 
> > issued by the GoDaddy and starfieldtech.com CAs.
> 
> You claim that the number of certs is less relevant than how widely
> those certs are used. So, how widely used are the 5 (!) out of 382860
> certificates that contain wildcard component fragments? The fact that
> those certificates were issued by GoDaddy and Starfield Technologies
> means nothing.

Very few commercial(!!) CAs (currently) issue wildcard certs at all.
And of those commercial CAs that offer wildcard certs, only a fraction
offers substring wildcard certs.

Just because commercial CAs don't do it, doesn't mean that a
DNS admin running his own CA would not want to do it either.


> 
> > I support Martin's arguments that the "f*.example.com" form specified in 
> > RFC 2818 should be supported.
> 
> What do you mean by "should be supported"?

That this paragraph:

   The client MUST fail to match a presented identifier
   in which the wildcard character is contained within a label fragment
   (e.g., baz*.example.net is not allowed and MUST NOT be taken to match
   baz1.example.net and baz2.example.net)

should be changed.

Out of curiosity I just check the behaviour of the following browsers:

   MSIE7 on XPsp3
   MSIE7 on W2K3sp2
   MSIE8 on Win7
   Firefox 3.0.17 (XPsp2)
   Firefox 3.5.9  (W2K3sp2)

and they all appear show the exact *SAME* behaviour with respect to the
following characteristics:

 wildcard in leftmost DNS label only:
   - YES: wildcard matching for "*.bar.example.com"
   - NO:  wildcard matching for "foo.*.example.com"
    
 wildcard substring match:
   - YES: wildcard matching for "fo*.bar.example.com"
   - NO:  other patterns "*oo.bar.example.com", "f*o.bar.example.com"

For comparison, I also tried Opera 8.54 (the only one I have lying around),
and it supports wildcards in multiple DNS labels as well as in arbitrary
positions of the label, such as "f*o.ba*.example.com", "*oo.bar.example.com"

While Opera 8.54 is within the scope of rfc-2818, I'm personally more
comfortable of the behaviour exhibited by MSIE/SChannel and Firefox 3.x.


> 
> I support #1 (with the proviso that it's an implementation decision for
> the relevant software developers whether they want to simplify their
> matching algorithms, based on a cost-benefit analysis of code complexity
> vs. a degraded user experience for less than 0.01% of issued
> certificates).

I would not have the slighest problem if server-id-check said that

   Clients MAY ignore hostname identifiers in certificates that
   contain a wildcard character in other than the leftmost DNS label,
   and clients MAY ignore hostname identifiers where the leftmost
   DNS label contains characters in addition to the wildcard character,
   which would require partial string matches.  Several web browsers
   have chosen a conservative approach to rfc-2818 wildcard substring
   match and support a partial wildcard only when the wildcard character
   appears at the end of the leftmost label, e.g. ""foo*.bar.example.com".


> 
> What are the positions of those who are arguing for supporting wildcard
> component fragments, and why?

I consider the conservative approach of MSIE/SChannel and Firefox to
allow a tail wildcard on the leftmost DNS label, in addition to a
full wildcard, sensitive risk management combined with minimal complexity.


-Martin