<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Feb 5, 2015 at 9:44 AM, Eddy Nigg <span dir="ltr"><<a href="mailto:eddy_nigg@startcom.org" target="_blank">eddy_nigg@startcom.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF" text="#000000"><span class="">
    <br>
    <div>On 02/05/2015 04:26 PM, Gervase Markham
      wrote:<br>
    </div>
    <blockquote type="cite">I'm
      not the person who argued for a restriction on *.<a href="http://facebook.com" target="_blank">facebook.com</a> EV<br>
    </blockquote>
    <br></span>
    I too might be wrong on this, but according to my memory I recall
    that you were the person arguing against it when we discussed it
    last time when we created the BR. :-)<br>
    <br>
    IIRC Wayne from Godaddy argued (correctly) that if wild cards should
    be restricted it would make most sense to have it supported by EV
    since it's the strongest verification standard currently. EV allows
    to include domain names of third parties (in my opinion
    incorrectly), so adding wild cards doesn't change that in any way
    really.<br>
    <br>
    We would be in favor for such a move and believe that wild cards
    have nothing lost in the non-verified (e.g. DV) settings due to
    their potential abuse. If at all, wild cards should be permitted
    with EV and prohibited for DV (if you want anything else than EV).</div></blockquote><div><br></div><div>At the risk of derailing the conversation, we'd be opposed to such a proposal (and have said so in the past)</div><div><br></div><div>To the topic at hand - as it relates specifically to .onion names:</div><div><br></div><div>The case for wildcards:</div><div>- The use of origins (RFC 6454 for those unfamiliar with the core concept of web security) provides an effective means to separate privileges and reduce the risks of compromise (in the web sense; this means issues such as XSS) and the privileges granted</div><div>- The use of separable origins can be beneficial-to-critical to high performance web pages (... unless/until the site is using HTTP/2), due to items such as connection pooling, request prioritization, etc</div><div><br></div><div>The case against wildcards:</div><div>- The primary argument against wildcards (for EV) is derived from Section 11.12.1 of EVG 1.5.2. EVG 1.5.2 requires all names be treated as High Risk (as defined in the BRs 1.2.3), which requires that the CA perform some degree of secondary checks (such as names listed on Miller Smiles or Safe Browsing). A wildcard cert allows an entity to request a potentially confusing name (<a href="http://bankofamericacom.facebook.com">bankofamericacom.facebook.com</a>) that may phish the user.</div><div>- The secondary argument against wildcards is derived from Section 11.7.1 p2 of EVG 1.5.2, the prohibition against mixed script. A wildcard allows a certificate holder to find any valid construction of IDNA/script at that subordinate domain that may exploit some confusible.</div><div><br></div><div>Now, I don't feel that the case against is at all strong or relevant. It's long been public record that we don't view certificates as an effective means against phishing, for a wide variety of reasons, and so phishing-level arguments are, to us, particularly specious. The argument against mixed script is also questionable, in as much as it's possible with DV, and it's an issue that browsers (and their rules regarding presentation of punycode vs native scripts) are already handling. For !browser clients, it might be relevant, but I would argue that the EVGs are not exactly relevant to the !browser case.</div><div><br></div><div><br></div><div>To the broader question about whether wildcards should be prevented or allowed in the EVGs, I suspect this will be the same tension and misaligned interests as the insurance discussion. CAs may perceive one set of value propositions, browsers another. The lack of wildcard support allows for greater price controls, which on a purely business level is a boon, but on a practical security level, would be unfortunate if CAs place profit over security.</div><div><br></div><div>However, if this does represent some set of concern for CAs (although I would argue unwarranted, for the reasons explained above), then I suspect it can be removed. It just means anyone wanting to use hidden services for accessibility (e.g. as Facebook is doing) will need to invest sizably more, or work out an appropriate cost structure with the CA that allows for bulk purchase, neither of which do much to change the security landscape any.</div></div></div></div>