<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi everyone,<br>
<br>
As we are trying to get ballots ready for when the ballot reforms
are done, here's a third version of the draft motion to make CAA
mandatory. Changes over version 2 are:<br>
<br>
* Add a further exception: "CAA checking is optional if the domain's
DNS is operated by the CA or an Affiliate." <br>
<br>
This is an attempt to help Jody with his request to not have to
check Microsoft's domains, while recognising that one part of the CA
asking another part of the CA to set some DNS records so it can
check them isn't really pointful.<br>
<br>
One change I am not making is that I am not persuaded that there are
compelling technical or business reasons to provide carve-outs for
enterprise or other accounts. Providing such carve-outs changes CAA
from "site policy" to "CA policy", and opens up loopholes which
could be used by CAs to not do CAA on occasions where it would be
appropriate. I feel the big benefit of CAA for sites is that it
allows them to control issuance by all CAs (especially those with
which they do not have a relationship) in a way which has not been
possible before, and I'm keen to preserve that benefit. While I
admit I have limited control over this, I'm also keen to encourage
CAs to implement CAA in way which is hard or impossible for CA
issuance staff to override, and if there are reasons they regularly
need to override it, CAs obviously won't do that.<br>
<br>
There are lots of ways a site owner can totally break their site by
changing their DNS. Adding "adds an adverse CAA record in a
situation where they need quick issuance" to that list doesn't, to
my mind, change the risk profile significantly. Of course, the
motion requires CAs to document problems encountered so if this
analysis proves wrong, they will be able to provide evidence.<br>
<br>
I am now seeking endorsers for this motion.<br>
<br>
Would anyone like to suggest the appropriate section of the BRs to
which the first section of text should be added?<br>
<br>
The proposal is that the effective date of this change (written into
the new section 2.2) should be six months after the voting period
ends. I am proposing six months rather than three because it
requires a reasonable amount of development work within a CA's
infrastructure.<br>
<br>
Gerv<br>
<p class="line874"><b>Ballot XXX - Make CAA Checking Mandatory<br>
</b></p>
<p class="line862">The following motion has been proposed by Gervase
Markham of Mozilla and endorsed by XXX of XXX and XXX of XXX: <o:p></o:p></p>
<p class="line874"><b>Statement of Intent</b>: <span class="anchor"
id="line-6"></span><span class="anchor" id="line-7"></span></p>
Certificate Authority Authorization (CAA) is a DNS Resource Record
defined in RFC 6844 - <a class="moz-txt-link-freetext"
href="https://datatracker.ietf.org/doc/rfc6844/">https://datatracker.ietf.org/doc/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 (except in
one or two uncommon cases), 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="anchor" id="line-13"></span><span class="anchor"
id="line-14"></span>
<p class="line874"><b>-- MOTION BEGINS --</b> <span class="anchor"
id="line-15"></span><span class="anchor" id="line-16"></span></p>
Add the following text to section XXX ("XXX") of the Baseline
Requirements:<br>
<blockquote>As part of the issuance process, the CA must check for a
CAA record for each dNSName in the subjectAltName extension of the
certificate to be issued, 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 the TTL of
the CAA record, or 1 hour, whichever is greater.<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 unless they are one of the following:<br>
<ul>
<li>CAA checking is optional for certificates for which a
Certificate Transparency pre-certificate was created and
logged in at least two public logs, and for which CAA was
checked.</li>
<li>CAA checking is optional for certificates issued by an
Technically Constrained Subordinate CA Certificate as set out
in Baseline Requirements section 7.1.5, where the lack of CAA
checking is an explicit contractual provision in the contract
with the Applicant.</li>
<li>CAA checking is optional if the domain's DNS is operated by
the CA or an Affiliate of the CA.</li>
</ul>
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's zone does not have a DNSSEC validation chain to
the ICANN root.</li>
</ul>
CAs MUST document 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 the CA’s policy or
practice on processing CAA Records for Fully Qualified Domain Names; that policy shall be consistent
with these Requirements. It shall clearly specify the set of Issuer Domain Names that the CA
recognises in CAA "issue" or "issuewild" records 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="anchor" id="line-45"></span><span
class="anchor" id="line-46"></span>
<p class="line874">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="anchor" id="line-47"></span><span class="anchor"
id="line-48"></span></p>
<p class="line862">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="https"
href="https://cabforum.org/members/">https://cabforum.org/members/</a>
<span class="anchor" id="line-49"></span><span class="anchor"
id="line-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.
</body>
</html>