[cabfpub] Ballot 187 - Make CAA Checking Mandatory

Moudrick M. Dadashov md at ssc.lt
Wed Mar 8 08:14:42 UTC 2017


SSC votes: "Yes".

Thanks,
M.D.

On 3/7/2017 9:09 PM, cornelia.enke--- via Public wrote:
>
> SwissSign votes “yes” on ballot 187.
>
> Best Regards Conny
>
> *Von:*Public [mailto:public-bounces at cabforum.org] *Im Auftrag von 
> *Gervase Markham via Public
> *Gesendet:* Mittwoch, 22. Februar 2017 22:35
> *An:* CABFPub
> *Cc:* Gervase Markham
> *Betreff:* [cabfpub] Ballot 187 - Make CAA Checking Mandatory
>
> Hi everyone,
>
> This ballot is now entering its seven-day discussion period. My 
> sincere thanks to everyone who helped shape the text into what it is 
> today.
>
> Changes from draft 3:
>
> * 1 hour changed to 8 hours as minimum caching time, to make manual 
> issuance easier.
>
> * Added text from Ryan, at Doug's suggestion, of exactly which 
> properties need to be supported.
>
> * Marked Jeremy and Ryan as endorsers (assuming they don't object to 
> the above changes).
>
> Gerv
>
> *Ballot 187 - 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 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 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/20170308/f250dd06/attachment-0003.html>


More information about the Public mailing list