Hi Gerv, I have some input and recommendations…..
I’ve attached an updated version of the ballot for your consideration with these comments (and maybe others, this has been a work-in-progress for a while and maybe some other changes crept in, sorry in advance) I think we need to talk about negative caching TTL. I recommend we add: - In the event there were no CAA records found, the CA may cache the result for 24-hours or the value of the negative caching TTL. You reference CT logs, but I think we need to be more clear that they need to be Active logs (anyone of the active logs on this page https://sites.google.com/site/certificatetransparency/known-logs). Not doing so could allow someone to generate a pre-cert and post it to their development CT log then wait a month/year before issuing the real cert at which point the CAA check is long over the time limit. I think we need to update the EVGL, section 11.7.1 - For each Fully-Qualified Domain Name listed in a Certificate, other than a Domain Name with .onion in the right-most label of the Domain Name, the CA SHALL confirm that, as of the date the Certificate was issued, the Applicant (or the Applicant’s Parent Company, Subsidiary Company, or Affiliate, collectively referred to as “Applicant” for the purposes of this section) either is the Domain Name Registrant or has control over the FQDN using a procedure specified in Section 3.2.2.4 of the Baseline Requirements and has checked CAA in accordance with Section 3.2.2.8 of the Baseline Requirements. For a Certificate issued to a Domain Name with .onion in the right-most label of the Domain Name, the CA SHALL confirm that, as of the date the Certificate was issued, the Applicant’s control over the .onion Domain Name in accordance with Appendix F. Several people have looked at RFC 6844 and have come away with different interpretations of what the processing means, so I HIGHLY recommend we include the CAA processing that MUST be performed so there is no ambiguity and so it’s clear for auditors. This includes statements like: - When performing CAA checking, the CA MUST climb the DNS name tree from the specified label up to but not including the DNS root '.'. Checking CAA means the CA MUST perform the checks specified in Appendix A prior to issuing, reissuing, renewing or rekeying a Certificate. Appendix A – CAA checking The following is pulled from RFC 6844 and expanded on slightly to clearly define the precise checks that MUST be performed for BR compliant CAA checking to assure consistent interpretation of CAA requirements: Let 1. CAA(X) be the record set returned in response to performing a CAA record query on the label X, 2. P(X) be the DNS label immediately above X in the DNS hierarchy, and 3. A(X) be the target of a CNAME or DNAME alias record specified at the label X. Then: 1. If CAA(X) is not empty, R(X) = CAA (X), otherwise 2. If CAA(X) is not null (i.e, there is a CNAME or DNAME record for X), and R(A(X)) is not empty, then R(X) = R(A(X)), otherwise 3. If X is not a Base Domain Name, then R(X) = R(P(X)) and perform check again starting at step 1, otherwise 4. R(X) is empty. · If any one of the returned records in R(X) contains a Domain Name from the set of the CA’s Issuer Domain Names, then the CA may issue the certificate. · If none of the records returned in R(X) contain any Domain Name from the set of the CA’s Issuer Domain Names, then the CA MUST NOT issue the certificate · If a CNAME or DNAME record is found, then the CAA check will be performed on the returned value.. Example 1 – Typical example with a CAA record Assume you want to find the CAA record for www.example.com and the CAA record is set on example.com, then the processing would be as follows: 1) CAA(www.example.com) – nothing 2) DNAME(www.example.com) – nothing 3) CNAME(www.example.com) – nothing 4) CAA(example.com) – value Example 2 – Typical example with no CAA record Assume you want to find the CAA record for www.example.com and there is no CAA record set, then the processing would be as follows: 1) CAA(www.example.com) – nothing 2) DNAME(www.example.com) – nothing 3) CNAME(www.example.com) – nothing 4) CAA(example.com) – nothing 5) DNAME(example.com) – nothing 6) CNAME(example.com) – nothing 7) CAA(com) – nothing 8) DNAME(com) – nothing 9) CNAME(com) - nothing Example 3 – Example with CNAME Assume you want to find the CAA record for foo.example.com and - foo.example.com has a CNAME to bar.example.net, and - the CAA record is set on "example.com" Then the processing would be as follows: 1) CAA(foo.example.com) - nothing 2) DNAME(foo.example.com) 3) CNAME(foo.example.com) - bar.example.net a. CAA(bar.example.net) - nothing b. DNAME(bar.example.net) – nothing c. CNAME(bar.example.net) - nothing d. CAA(example.net) – nothing e. DNAME(example.net) - nothing f. CNAME(example.net) - nothing g. CAA(net) - nothing h. DNAME(net) - nothing i. CNAME(net) - nothing 4) CAA(example.com) - value From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Gervase Markham via Public Sent: Wednesday, February 22, 2017 4:35 PM To: CABFPub <public@cabforum.org> Cc: Gervase Markham <g...@mozilla.org> Subject: [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.
GlobalSign comments on Ballot 187.docx
Description: GlobalSign comments on Ballot 187.docx
_______________________________________________ Public mailing list Public@cabforum.org https://cabforum.org/mailman/listinfo/public
