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/ _______________________________________________ certid mailing list [email protected] https://www.ietf.org/mailman/listinfo/certid
