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

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

On 10/12/10 7:10 PM, Matt McCutchen wrote:
> On Tue, 2010-10-12 at 18:34 -0600, Peter Saint-Andre wrote:
>> On 10/12/10 5:51 PM, Matt McCutchen wrote:
>>> On Wed, 2010-10-13 at 01:34 +0200, Martin Rex wrote:
>>>> 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.
>>>
>>> As I said before, I don't think this "risk management" argument is real.
>>> CAs are responsible for not giving an entity a certificate that matches
>>> names the entity does not own.  Why should we believe they are any more
>>> likely to mess up via wildcards than, e.g., by setting the basic
>>> constraint "CA: true"?
>>
>> Matt, what conclusion do you draw from your statement? IMHO it might
>> lead to the conclusion that it doesn't matter what we put in the
>> left-most label -- or even the conclusion that we don't need to restrict
>> the location of the wildcard (e.g., foo.*.example.com or even
>> *.*.example.com is fine) -- as long as the CA issues a certificate that
>> matches a name the entity owns.
> 
> That's right from the perspective of "risk management".  All I wanted to
> do was put that argument aside. 

I see, and I agree.

> There are other arguments to consider,
> e.g., "simpler" algorithms are easier to implement and more likely to be
> implemented correctly, 

That seems to be the operative consideration. Martin claimed that it is
a "conservative approach ... to allow a tail wildcard on the leftmost
DNS label" but RFC 2818 doesn't say anything about a "tail wildcard"
(e.g., foo*):

   Names may contain the wildcard
   character * which is considered to match any single domain name
   component or component fragment. E.g., *.a.com matches foo.a.com but
   not bar.foo.a.com. f*.com matches foo.com but not bar.com.

Yes, the example here shows a tail wildcard, but as far as I can see the
rule of allowing the wildcard character in a component fragment does not
restrict '*' to the tail -- it could just as well be a "front wildcard"
(e.g., *oo) or a "middle wildcard" (e.g., f*o). All of these increase
the complexity of the matching algorithm, for very little if any gain
that I can see.

> and compatibility with specifications that might
> want to update to reference tls-server-id-check.

Well, that's not a legitimate argument because it begs the question. :)

Peter

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