[cabfpub] Draft CAA motion
eric at konklone.com
Mon Nov 7 22:22:42 UTC 2016
Actually, scratch my comment -- that was based on a misunderstanding of DS
On Mon, Nov 7, 2016 at 3:27 PM, Eric Mill <eric at konklone.com> wrote:
> 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
> -- 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.
>> *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, 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
>> 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
>> 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.
>> Public mailing list
>> Public at cabforum.org
> konklone.com | @konklone <https://twitter.com/konklone>
konklone.com | @konklone <https://twitter.com/konklone>
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Public