<div dir="ltr">Actually, scratch my comment -- that was based on a misunderstanding of DS records.<div><br></div><div>-- Eric</div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Nov 7, 2016 at 3:27 PM, Eric Mill <span dir="ltr"><<a href="mailto:eric@konklone.com" target="_blank">eric@konklone.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">The line "the domain does not use DNSSEC." is a bit tricky, because it's not possible to reliably discern whether a domain uses DNSSEC (without a "DNSSEC preload list"). An active attacker could make it appear that the domain does not support DNSSEC.<div><br></div><div>Since the CAA spec recommends but does not require the use of DNSSEC, I think the ballot should either be silent on DNSSEC altogether, or language about DNSSEC should just specify whether or not DNSSEC connections must be attempted.</div><div><br></div><div>-- Eric</div></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="m_979280054694102690h5">On Mon, Nov 7, 2016 at 11:01 AM, Gervase Markham via Public <span dir="ltr"><<a href="mailto:public@cabforum.org" target="_blank">public@cabforum.org</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="m_979280054694102690h5">
  
    
  
  <div bgcolor="#FFFFFF" text="#000000">
    Hi everyone,<br>
    <br>
    Here's a draft motion to make CAA mandatory. We may not be able to
    start the process properly for a while, but I'd like to get the
    motion text ironed out.<br>
    <br>
    Gerv<br>
    <p class="m_979280054694102690m_-6673891890298233430m_-5253163159542736972line874"><b>Ballot XXX - Make CAA Checking Mandatory<br>
      </b></p>
    <p class="m_979280054694102690m_-6673891890298233430m_-5253163159542736972line862">The following motion has been proposed by Gervase
      Markham of Mozilla and endorsed by XXX of XXX and XXX of XXX: <u></u><u></u></p>
    <p class="m_979280054694102690m_-6673891890298233430m_-5253163159542736972line874"><b>Statement of Intent</b>: <span class="m_979280054694102690m_-6673891890298233430m_-5253163159542736972anchor" id="m_979280054694102690m_-6673891890298233430m_-5253163159542736972line-6"></span><span class="m_979280054694102690m_-6673891890298233430m_-5253163159542736972anchor" id="m_979280054694102690m_-6673891890298233430m_-5253163159542736972line-7"></span></p>
    Certificate Authority Authorization (CAA) is a DNS Resource Record
    defined in RFC 6844 - <a class="m_979280054694102690m_-6673891890298233430m_-5253163159542736972moz-txt-link-freetext" href="https://datatracker.ietf.org/doc/rfc6844/" target="_blank">https://datatracker.ietf.org/d<wbr>oc/rfc6844/</a>
    , published in January 2013. It allows a DNS domain name holder to
    specify one or more Certification Authorities (CAs) authorized to
    issue certificates for that domain and, by consequence, that no
    other CAs are authorized.<br>
    <br>
    The intent of this motion is to make it mandatory for CAs to check
    CAA records at issuance time for all certificates issued, and to
    prevent issuance if a CAA record is found which does not permit
    issuance by that CA. This therefore allows domain owners to set an
    issuance policy which will be respected by all publicly-trusted CAs,
    and allows them to mitigate the problem that the public CA trust
    system is only as strong as its weakest CA.<br>
    <br>
    Note that CAA is already a defined term in the BRs and so does not
    need definitional text to be provided by this motion.<span class="m_979280054694102690m_-6673891890298233430m_-5253163159542736972anchor" id="m_979280054694102690m_-6673891890298233430m_-5253163159542736972line-13"></span><span class="m_979280054694102690m_-6673891890298233430m_-5253163159542736972anchor" id="m_979280054694102690m_-6673891890298233430m_-5253163159542736972line-14"></span>
    <p class="m_979280054694102690m_-6673891890298233430m_-5253163159542736972line874"><b>-- MOTION BEGINS --</b> <span class="m_979280054694102690m_-6673891890298233430m_-5253163159542736972anchor" id="m_979280054694102690m_-6673891890298233430m_-5253163159542736972line-15"></span><span class="m_979280054694102690m_-6673891890298233430m_-5253163159542736972anchor" id="m_979280054694102690m_-6673891890298233430m_-5253163159542736972line-16"></span></p>
    Add the following text to section XXX ("XXX") of the Baseline
    Requirements:<br>
    <blockquote>As part of the issuance process, after all other
      validation has been completed. The CA must check for a CAA record
      for all domains in the certificate according to the procedure in
      RFC 6844, following the processing instructions set down in RFC
      6844 for any records found. If the CA issues, they must do so
      within 10<br>
      minutes of the check passing.<br>
      <br>
      This stipulation does not prevent the CA from checking CAA records
      at other points in the issuance process.<br>
      <br>
      RFC 6844 requires that CAs "MUST NOT issue a certificate unless
      either (1) the certificate request is consistent with the
      applicable CAA Resource Record set or (2) an exception specified
      in the relevant Certificate Policy or Certification Practices
      Statement applies." For issuances conforming to these Baseline
      Requirements, CAs MUST NOT rely on any exceptions specified in
      their CP or CPS.<br>
      <br>
      CAs MUST keep records of the responses to all CAA DNS requests.
      CAs are permitted to treat a record lookup failure as permission
      to issue if:<br>
      <ul>
        <li>the failure is outside the CA's infrastructure; <br>
        </li>
        <li>the lookup has been retried at least once; and <br>
        </li>
        <li>the domain does not use DNSSEC.</li>
      </ul>
      CAs MUST log issuances that were prevented by an adverse CAA
      record in sufficient detail to provide feedback to the CAB Forum
      on the circumstances, and SHOULD report such requests to the
      contact(s) stipulated in the CAA iodef record(s), if present. CAs
      are not expected to support URL schemes in the iodef record other
      than mailto: or https:.</blockquote>
    Update section 2.2 ("Publication of Information") of the Baseline
    Requirements, to remove the following text:<br>
    <pre>    Effective as of 15 April 2015, section 4.2 of a CA's Certificate Policy and/or Certification 
    Practice Statement (section 4.1 for CAs still conforming to RFC 2527) SHALL state whether 
    the CA reviews CAA Records, and if so, the CA’s policy or practice on processing CAA Records 
    for Fully Qualified Domain Names. The CA SHALL log all actions taken, if any, consistent with 
    its processing practice.  </pre>
    and replace it with:
    <pre>    Effective as of XXX, section 4.2 of a CA's Certificate Policy and/or Certification 
    Practice Statement (section 4.1 for CAs still conforming to RFC 2527) SHALL state that 
    the CA reviews CAA Records for all issuances, and the CA’s policy or practice on processing CAA Records 
    for Fully Qualified Domain Names. It shall clearly specify the set of Issuer Domain Names that the CA
    recognises as permitting it to issue. The CA SHALL log all actions taken, if any, consistent with 
    its processing practice.  

Add the following text to the appropriate place in section 1.6.3 ("References"):
</pre>
    <blockquote>RFC6844, Request for Comments: 6844, DNS Certification
      Authority Authorization (CAA) Resource Record, Hallam-Baker,
      Stradling, January 2013. <br>
    </blockquote>
    <b>-- MOTION ENDS -- </b><span class="m_979280054694102690m_-6673891890298233430m_-5253163159542736972anchor" id="m_979280054694102690m_-6673891890298233430m_-5253163159542736972line-45"></span><span class="m_979280054694102690m_-6673891890298233430m_-5253163159542736972anchor" id="m_979280054694102690m_-6673891890298233430m_-5253163159542736972line-46"></span>
    <p class="m_979280054694102690m_-6673891890298233430m_-5253163159542736972line874">The review period for this ballot shall commence
      at 2200 UTC on XXX, and will close at 2200 UTC on XXX. Unless the
      motion is withdrawn during the review period, the voting period
      will start immediately thereafter and will close at XXX. Votes
      must be cast by posting an on-list reply to this thread. <span class="m_979280054694102690m_-6673891890298233430m_-5253163159542736972anchor" id="m_979280054694102690m_-6673891890298233430m_-5253163159542736972line-47"></span><span class="m_979280054694102690m_-6673891890298233430m_-5253163159542736972anchor" id="m_979280054694102690m_-6673891890298233430m_-5253163159542736972line-48"></span></p>
    <p class="m_979280054694102690m_-6673891890298233430m_-5253163159542736972line862">A vote in favor of the motion must indicate a
      clear 'yes' in the response. A vote against must indicate a clear
      'no' in the response. A vote to abstain must indicate a clear
      'abstain' in the response. Unclear responses will not be counted.
      The latest vote received from any representative of a voting
      member before the close of the voting period will be counted.
      Voting members are listed here: <a class="m_979280054694102690m_-6673891890298233430m_-5253163159542736972https" href="https://cabforum.org/members/" target="_blank">https://cabforum.org/members/</a>
      <span class="m_979280054694102690m_-6673891890298233430m_-5253163159542736972anchor" id="m_979280054694102690m_-6673891890298233430m_-5253163159542736972line-49"></span><span class="m_979280054694102690m_-6673891890298233430m_-5253163159542736972anchor" id="m_979280054694102690m_-6673891890298233430m_-5253163159542736972line-50"></span></p>
    In order for the motion to be adopted, two thirds or more of the
    votes cast by members in the CA category and greater than 50% of the
    votes cast by members in the browser category must be in favor.
    Quorum is currently XXX members – at least that many members must
    participate in the ballot, either by voting in favor, voting
    against, or abstaining.
  </div>

<br></div></div>______________________________<wbr>_________________<br>
Public mailing list<br>
<a href="mailto:Public@cabforum.org" target="_blank">Public@cabforum.org</a><br>
<a href="https://cabforum.org/mailman/listinfo/public" rel="noreferrer" target="_blank">https://cabforum.org/mailman/l<wbr>istinfo/public</a><br>
<br></blockquote></div><span class="m_979280054694102690HOEnZb"><font color="#888888"><br><br clear="all"><div><br></div>-- <br><div class="m_979280054694102690m_-6673891890298233430gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><a href="https://konklone.com" target="_blank">konklone.com</a> | <a href="https://twitter.com/konklone" target="_blank">@konklone</a><br></div></div></div></div></div></div></div>
</font></span></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="m_979280054694102690gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><a href="https://konklone.com" target="_blank">konklone.com</a> | <a href="https://twitter.com/konklone" target="_blank">@konklone</a><br></div></div></div></div></div></div></div>
</div></div>