[cabfpub] Draft CAA motion

Mon Nov 7 13:27:41 MST 2016

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.

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.

-- Eric

On Mon, Nov 7, 2016 at 11:01 AM, Gervase Markham via Public <
public at cabforum.org> wrote:

> 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.
>
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public
>
>

-- 
konklone.com | @konklone <https://twitter.com/konklone>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/public/attachments/20161107/5aaee6d4/attachment.html>