[cabfpub] Ballot 187 - Make CAA Checking Mandatory
Dimitris Zacharopoulos
jimmy at it.auth.gr
Tue Mar 7 09:15:32 UTC 2017
HARICA votes "yes" to ballot 187.
Dimitris.
On 3/3/2017 11:18 πμ, Gervase Markham via Public wrote:
>
> On 03/03/17 02:06, Dean Coclin wrote:
>
>> Hi Gerv,
>> Did you already publish a revised ballot somewhere? I recall seeing the original ballot but not a revised one. It would be helpful just to have a full, final ballot.
>
> I did not, as the change was so minor. But your wish is my command :-)
>
> Gerv
>
> *Ballot 187 v2 - Make CAA Checking Mandatory
> *
>
> The following motion has been proposed by Gervase Markham of Mozilla
> and endorsed by Jeremy Rowley of DigiCert and Ryan Sleevi of Google:
>
> *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 implication, 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 (except in a few
> special 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.
>
> *-- MOTION BEGINS --*
>
> Add the following text as a new section 3.2.2.8 (titled "CAA Records")
> of the Baseline Requirements:
>
> This section is effective as of 8 September 2017.
>
> 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 8 hours, whichever is greater.
>
> This stipulation does not prevent the CA from checking CAA records
> at any other time.
>
> When processing CAA records, CAs MUST process the issue,
> issuewild, and iodef property tags as specified in RFC 6844.
> Additional property tags MAY be supported, but MUST NOT conflict
> with or supersede the mandatory property tags set out in this
> document. CAs MUST respect the critical flag and reject any
> unrecognized properties with this flag set.
>
> 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 CA or an Affiliate of the CA
> is the DNS Operator (as defined in RFC 7719
> <https://tools.ietf.org/html/rfc7719>) of the domain's DNS.
>
> 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 potential issuances that were prevented by a CAA
> record in sufficient detail to provide feedback to the CAB Forum
> on the circumstances, and SHOULD dispatch reports of such issuance
> 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 8 September 2017, 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 procedure for approval of this Final Maintenance Guideline ballot
> is as follows:
>
> BALLOT 187
>
> Status: Maintenance Guideline
>
>
>
> Start time (22:00 UTC)
>
>
>
> End time (22:00 UTC)
>
> Discussion (7 to 14 calendar days)
>
>
>
> 2017-02-22
>
>
>
> 2017-03-01
>
> Vote for approval (7 calendar days)
>
>
>
> 2017-03-01
>
>
>
> 2017-03-08
>
> If vote approves ballot: Review Period (Chair to send Review Notice)
> (30 calendar days).
>
> If Exclusion Notice(s) filed, ballot approval is rescinded and PAG to
> be created.
>
> If no Exclusion Notices filed, ballot becomes effective at end of
> Review Period.
>
>
>
> Upon filing of Review Notice by Chair
>
>
>
> 30 days after filing of Review Notice by Chair
>
> From Section 2.3 of the Bylaws: If the Draft Guideline Ballot is
> proposing a Final Maintenance Guideline, such ballot will include a
> redline or comparison showing the set of changes from the Final
> Guideline section(s) intended to become a Final Maintenance Guideline,
> and need not include a copy of the full set of guidelines. Such
> redline or comparison shall be made against the Final Guideline
> section(s) as they exist at the time a ballot is proposed, and need
> not take into consideration other ballots that may be proposed
> subsequently, except as provided in Section 2.3(j) of the Bylaws.
>
> Votes must be cast by posting an on-list reply to this thread on the
> Public Mail List. 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 (2/3) 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 vote “yes”. Quorum
> is shown on CA/Browser Forum wiki. Under Section 2.2(g) of the Bylaws,
> at least the required quorum number of voting members must participate
> in the ballot for the ballot to be valid, either by voting in favor,
> voting against, or abstaining.
>
>
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170307/12458edc/attachment-0003.html>
More information about the Public
mailing list