[cabfpub] Draft CAA motion

[Doug Beattie]

Gerv,

I have a few comments:


1)      We’ve gone from at the time of validation (up to 39 months, which I agree is unreasonable) to a few days (I think Ryan suggested this) to 10 minutes.  I recommend we increase this back to a few days (let’s say 3).  This will allow more flexibility in the location of this check in the overall process, reduce the number duplicate checks CAs need to make (one when order is placed, again when validated (maybe) and one when issued) and will help reduce the “last minute” checks that need to be done and which can impact issuance.  I think a few days still allows a sufficiently short cache time that this should address domain owners concerns for rolling out updated CAA records.  What’s driving the 10 minute requirement?

2)      I think there should be a provision that CAA can be done contractually such that those customers that own the domain can provide CAA approval for their Domain Name to the CA so that each of the FQDNs don’t need to be checked at issuance time, for the duration of the contract.  Mozilla allows this type of flexibility when issuing client certificates:

·         “…the CA takes reasonable measures to verify that the entity submitting the request controls the email account associated with the email address referenced in the certificate or has been authorized by the email account holder to act on the account holder’s behalf

3)      I strongly object to this statement – why should blocking issuance for a CAA record be any different than blocking issuance based on key word or high risk checks?  I can’t support this – why does CABF need the results of CAA checks?

·         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

4)      Specifying what is logged is a bit over the top also.  The requirement should be to perform CAA and not drive implementation on what is logged.  I searched the BRs for logging requirements and there no existing logging requirements this specific, so I recommend these statements should be dropped:

·         CAs MUST keep records of the responses to all CAA DNS requests

·         CAs MUST log issuances that were prevented by an adverse CAA record

·         Section 2.2 “The CA SHALL log all actions taken, if any, consistent with its processing practice”

5)      I don’t understand this statement:

·         “It shall clearly specify the set of Issuer Domain Names that the CA recognises as permitting it to issue.”


Doug

From: Public [mailto:public-bounces at cabforum.org] On Behalf Of Gervase Markham via Public
Sent: Monday, November 7, 2016 11:02 AM
To: CABFPub <public at cabforum.org>
Cc: Gervase Markham <gerv at mozilla.org>
Subject: [cabfpub] Draft CAA motion

Hi everyone,

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.

Gerv

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

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.

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

-- MOTION BEGINS --
Add the following text to section XXX ("XXX") of the Baseline Requirements:
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
minutes of the check passing.

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.

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:

  *   the failure is outside the CA's infrastructure;
  *   the lookup has been retried at least once; and
  *   the domain does not use DNSSEC.
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:.
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 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"):
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: https://cabforum.org/members/
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://cabforum.org/pipermail/public/attachments/20161109/e4376075/attachment-0001.html>