<div dir="ltr">Just resurrecting this for the new year, and hoping people have had a chance to look at data.<div><br></div><div>We'll work on circulating a concrete draft for the next call to accomplish this, but would love to have data to inform the timelines.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Dec 18, 2020 at 9:45 AM Ryan Sleevi via Validation <<a href="mailto:validation@cabforum.org">validation@cabforum.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Yes, that is correct in how Authorization Domain Names and Wildcard Domain Names work, and precisely what this proposal sets forward to accomplish. This is because demonstrating the ability to edit a file on the web server is not equivalent to demonstrating you have controlver over DNS, as the other validation methods achieve, and is equivalent more to demonstrating control over an TLS handshake, where we have intentionally limited in the same way.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Dec 18, 2020 at 4:55 AM Adriano Santoni via Validation <<a href="mailto:validation@cabforum.org" target="_blank">validation@cabforum.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
  
    
  
  <div>
    <p><font face="Calibri">Ryan,</font></p>
    <p><font face="Calibri">do I understand correctly that your post
        below implies the following? (first bullet is just a typical
        example, of course it would be the same for all subdomains)<br>
      </font></p>
    <ul>
      <li><font face="Calibri">if domain validation is passed on (say) <font color="#0000ff">domain.tld</font> by the website change
          method (</font><font face="Calibri">§3.2.2.4.6), then a
          certificate containing <font color="#0000ff"><a href="http://www.domain.tld" target="_blank">www.domain.tld</a> </font>MUST
          NOT be issued</font></li>
      <li><font face="Calibri">if domain validation is passed on (say) <font color="#0000ff">domain.tld </font>by the website change
          method (§3.2.2.4.6), then a certificate containing <font color="#0000ff">*.domain.tld</font> MUST NOT be issued<br>
        </font></li>
    </ul>
    <p><font face="Calibri">Adriano</font></p>
    <p><font face="Calibri"></font><br>
    </p>
    <div>Il 03/12/2020 02:31, Ryan Sleevi via
      Validation ha scritto:<br>
    </div>
    <blockquote type="cite">
      
      <div dir="ltr">Hey all,
        <div><br>
        </div>
        <div>I know we're not quite done with the certificate profile
          work, and I'm not wanting to distract from that too much.
          However, one of the long-standing items we had from our
          Herndon, VA validation summit (from Meeting 43) was in
          harmonizing the rules around what 3.2.2.4 methods can be used
          for Authorization Domain Names / Wildcard Domain Names.</div>
        <div><br>
        </div>
        <div>I made an initial attempt at <a href="https://github.com/cabforum/servercert/compare/main...sleevi:2020-12-01_Wildcard_Rules" target="_blank">https://github.com/cabforum/servercert/compare/main...sleevi:2020-12-01_Wildcard_Rules</a>
          to capture this. In effect, allowing validation as an ADN is
          conceptually "the same as" allowing a Wildcard Domain Name,
          since the ADN can authorize all children/grandchildren/etc of
          a domain, and a Wildcard is just a cert that works for all
          children of a domain.</div>
        <div><br>
        </div>
        <div>As we've become aware of some CAs having poorly evaluated
          the security risks in this space, we'd like to try to close
          this gap. Here's the TL;DR summary</div>
        <div><br>
        </div>
        <div>
          <ul>
            <li>3.2.2.4.6: Agreed-upon Change to Website</li>
            <ul>
              <li>Sunset 2020-06-03 for new validations</li>
            </ul>
            <li>3.2.2.4.18: Agreed-upon Change to Website v2</li>
            <li>3.2.2.4.19: Agreed-upon Change to Website - ACME</li>
          </ul>
          <div>(The other bits are just aligning some of the language,
            so that "MAY NOT" becomes a clearer "MUST NOT", even though
            we mean the same)</div>
          <div><br>
          </div>
          <div>These methods are proposed to *only* authorize a single
            FQDN, because they only demonstrate control over a specific
            service/port on a specific FQDN, and not demonstration of
            control over the whole domain namespace. This aligns with
            3.2.2.4.20 (TLS using ALPN), which also only demonstrates
            control over a single service/port on a single FQDN.</div>
        </div>
        <div><br>
        </div>
        <div>This doesn't touch 3.2.2.4.4 (Constructed Email to Domain
          Contact), although we identified that one as potentially
          messy. However, hopefully we'll see that one fully sunset
          separately, in favor of the improved CAA methods (.13 - .17).</div>
        <div><br>
        </div>
        <div>It'd be useful to spend a few minutes on the call
          discussing folks initial reactions. The big question, as
          always, is going to be timelines for changes. If folks think
          more time is needed than "immediately", my request is that
          they'd share concrete data.</div>
        <div><br>
        </div>
        <div>Since Ballot 190 (2017-09-19), CAs have been required to
          maintain records of the validation methods they use, so this
          "should" be as easy as scanning all unexpired validations for
          these three methods and identifying cetrs which have a SAN
          that doesn't equal the validated FQDN (e.g. a cert with "<a href="http://www.example.com" target="_blank">www.example.com</a>"
          when the method used was 3.2.2.4.6 for "<a href="http://example.com" target="_blank">example.com</a>").
          Just sharing those numbers is useful to understand any
          challenges CAs might face.</div>
        <div><br>
        </div>
        <div>For example: </div>
        <div>
          <ul>
            <li>30% of our certificates used 3.2.2.4.6. Of that 30%:</li>
            <ul>
              <li>80% of our certificates had at least one FQDN
                validated by ADN, with 40% of that being "www.".</li>
              <li>Of the 20% that had >1, we saw an average of 7.3
                additional FQDNs validated by FDN.</li>
            </ul>
            <li>17% of our certificates used 3.2.2.4.18. of that 17%
              ....</li>
            <ul>
              <li>80% of the FQDNs validated by ADNs were for domains
                that did not resolve (e.g. "internal.corp.foo.example"),
                and thus would have to switch to a new validation method
                or expose those services publicly.</li>
            </ul>
          </ul>
          <div>This sort of concrete data helps understand the impact to
            CAs, and their customers, and thus indirectly, our users. It
            also helps figure out what reasonable time frames to phase
            in could be, in the unlikely event a phase-in became
            necessary.</div>
        </div>
        <div><br>
        </div>
        <div>This sunset "should" be fairly simple and uncontroversial,
          but since there are edge cases (like internal servers),
          concrete data like the above is useful if folks have concerns.</div>
      </div>
      <br>
      <fieldset></fieldset>
      <pre>_______________________________________________
Validation mailing list
<a href="mailto:Validation@cabforum.org" target="_blank">Validation@cabforum.org</a>
<a href="https://lists.cabforum.org/mailman/listinfo/validation" target="_blank">https://lists.cabforum.org/mailman/listinfo/validation</a>
</pre>
    </blockquote>
  </div>

_______________________________________________<br>
Validation mailing list<br>
<a href="mailto:Validation@cabforum.org" target="_blank">Validation@cabforum.org</a><br>
<a href="https://lists.cabforum.org/mailman/listinfo/validation" rel="noreferrer" target="_blank">https://lists.cabforum.org/mailman/listinfo/validation</a><br>
</blockquote></div></div>
_______________________________________________<br>
Validation mailing list<br>
<a href="mailto:Validation@cabforum.org" target="_blank">Validation@cabforum.org</a><br>
<a href="https://lists.cabforum.org/mailman/listinfo/validation" rel="noreferrer" target="_blank">https://lists.cabforum.org/mailman/listinfo/validation</a><br>
</blockquote></div>