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