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

[Peter Saint-Andre <[e-mail]>]

On 10/12/10 4:00 AM, Joe Orton wrote:
> On Mon, Oct 11, 2010 at 12:43:29PM -0600, Peter Saint-Andre wrote:
>> Speaking of which, someone contacted Jeff and me off-list about some
>> research results showing that of a very large number of certificates
>> presented by TLS-protected websites, less than 0.01% contain wildcards
>> in component fragments. Given that minuscule level of deployment, I
>> don't see good reasons to spend more cycles on the topic.
> 
> The relative number of certs is less relevant than how widely those 
> certs are used, surely.  I checked the "top 1m sites" database from:
> 
> 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.

> 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"? I see several claims that one
could make:

1. Existing software whose matching algorithms support wildcard
component fragments should stay as-is.

1a. Any new software written to perform identity matching should also
contain matching algorithms that support wildcard component fragment.

2. Existing application protocols (see Appendix A of this I-D) that
allow wildcard component fragments should not be changed.

2a. Any new application protocols developed by the IETF (or other SDOs)
should also allow wildcard component fragments.

3. Wildcard component fragments are a best current practice for both
certificate issuance and certificate validation, and therefore any BCP
produced by the IETF at this time should recommend that all application
protocols should support wildcard component fragments (thus putting at
least RFC 5922 out of compliance, since that spec doesn't even allow
complete wildcard components).

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 think #1a depends on which application protocol the
software is designed to use (e.g., HTTP vs. SIP) -- conform to the spec
you're implementing. I think #2 is just fine (with the proviso that such
application protocols might decide to update their specs in the future
based on experience and discussion within the relevant technology
community). I disagree with #2a because I think that wildcard component
fragments are not a *best* current practice, and I disagree with #3 for
the same reason.

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

Peter

-- 
Peter Saint-Andre
https://stpeter.im/