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

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

On 10/7/10 8:00 PM, Martin Rex wrote:
> Matt McCutchen wrote:
>>
>> I have never seen a certificate with a wildcard that is not a
>> whole label on a public web site.
> 
> Btw. the use of TLS is not limited to the public internet.

I don't think anyone said it is. However, it's difficult for researchers
to do much testing of sites that are closed off from the public
internet, so that's the real-world data that folks tend to mention.

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.

> I don't think that know which _public_ website uses this is meaningless.
> The matching is implemented on the client anyway, not on the server.

Yes it is, but requiring significantly more complex matching to handle
less than 0.01% of the issued certificates seems like a bad idea, i.e.,
not a *best* current practice.

> A much more interesting question would be, what exact kind of wildcard
> matching do popular TLS clients actually implement?

Why is that a much more interesting question?

>    - Microsoft SChannel on XP/2003, Vista/Win7 
>    - Firefox 3.x
>    - Google Chrome
>    - Apple Safari (non-Windows)
>    - Opera
> 
> We started shipping SSL with our app in 2000/2001.  Back then,
> I noticed that MSIE 5.0x implemented (full-label) wildcard matching
> (i.e. WinNT 4 and Win9x/ME), but SChannel in Windows 2000 and therefore
> MSIE 5.0x on Windows 2000 did _NOT_ implement wildcard matching.
> For internal testing, I've been using server certs with wildcard CN-IDs
> since 2000, but not being aware of the wildcards substring matching
> described in rfc2818 back then, I never tried that myself.
> 
> I did issue server certs for wildcard substring matching when I
> implemented rfc-2818, though -- and I consider it likely that other
> implementors did this as well.

That's nice, but not directly relevant to the current discussion because
the I-D that Jeff and I have worked on does not override, supersede, or
obsolete RFC 2818 or any other prior art about matching rules for
application server identity. Instead, we are attempting to abstract from
that prior art to formulate forward-looking rules that capture the best
aspects of current practice in a form that future application protocols
can reference. If someday folks in the HTTP community wish to update or
obsolete RFC 2818 by referencing this I-D, they will be free to do so --
but that is not the purpose of the work that Jeff and I have done.

Peter

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