[cabfpub] Draft CAA motion (3)

Gervase Markham gerv at mozilla.org
Thu Jan 12 14:25:03 UTC 2017

Hi everyone,

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:

* Add a further exception: "CAA checking is optional if the domain's DNS
is operated by the CA or an Affiliate."

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.

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.

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.

I am now seeking endorsers for this motion.

Would anyone like to suggest the appropriate section of the BRs to which
the first section of text should be added?

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.


*Ballot XXX - Make CAA Checking Mandatory

The following motion has been proposed by Gervase Markham of Mozilla and
endorsed by XXX of XXX and XXX of XXX:

*Statement of Intent*:

Certificate Authority Authorization (CAA) is a DNS Resource Record
defined in RFC 6844 - https://datatracker.ietf.org/doc/rfc6844/ ,
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

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.

Note that CAA is already a defined term in the BRs and so does not need
definitional text to be provided by this motion.


Add the following text to section XXX ("XXX") of the Baseline Requirements:

    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.

    This stipulation does not prevent the CA from checking CAA records
    at other points in the issuance process.

    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:

      * 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.
      * 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.
      * CAA checking is optional if the domain's DNS is operated by the
        CA or an Affiliate of the CA.

    CAs are permitted to treat a record lookup failure as permission to
    issue if:

      * the failure is outside the CA's infrastructure;
      * the lookup has been retried at least once; and
      * the domain's zone does not have a DNSSEC validation chain to the
        ICANN root.

    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:.

Update section 2.2 ("Publication of Information") of the Baseline
Requirements, to remove the following text:

    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.  

and replace it with:

    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"):

    RFC6844, Request for Comments: 6844, DNS Certification Authority
    Authorization (CAA) Resource Record, Hallam-Baker, Stradling,
    January 2013.

*-- MOTION ENDS -- *

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.

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:

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170112/62dd63c5/attachment-0002.html>

More information about the Public mailing list