Ballot 187 – Make CAA Checking Mandatory

Ballot overview

• Ballot 187, Make CAA Checking Mandatory, was a Final Maintenance Guideline ballot in the Server Certificate Working Group.
• The ballot required CAs to check CAA records during issuance for each dNSName in the subjectAltName extension, following RFC 6844.
• It also required CAs to document prevented issuances, support specified CAA property tags, respect the critical flag, and update CP/CPS disclosure language about CAA processing.

Voting result

• The voting period ended and the page states that Ballot 187 passes.
• CA voting: 17 yes, 1 no, 1 abstain; quorum was met and the approval threshold was met.
• Browser voting: 3 yes, 0 no, 0 abstain; the approval threshold was met.
• The ballot page states that at least one CA Member and one browser Member voted in favor.

Effective dates and applicability

• The new CAA Records section was stated to be effective as of 8 September 2017.
• The replacement CP/CPS disclosure language was also stated to be effective as of 8 September 2017.
• CAA checking was optional in these cases:
  • Certificates for which a Certificate Transparency pre-certificate was created and logged in at least two public logs, and for which CAA was checked.
  • Certificates issued by a Technically Constrained Subordinate CA Certificate under Baseline Requirements section 7.1.5, where the lack of CAA checking is an explicit contractual provision in the contract with the Applicant.
  • Cases where the CA or an Affiliate of the CA is the DNS Operator of the domain’s DNS.
• CAs were permitted to treat certain lookup failures as permission to issue if the failure was outside the CA’s infrastructure, the lookup had been retried at least once, and the domain’s zone did not have a DNSSEC validation chain to the ICANN root.

Required CA actions

• Check for a CAA record for each dNSName in the subjectAltName extension of the certificate to be issued.
• Follow RFC 6844 processing instructions for any records found.
• If issuing, do so within the TTL of the CAA record or 8 hours, whichever is greater.
• Process the issue, issuewild, and iodef property tags as specified in RFC 6844.
• Support additional property tags only if they do not conflict with or supersede the mandatory tags.
• Reject unrecognized properties with the critical flag set.
• Not rely on CP or CPS exceptions unless they fall within the listed optional cases.
• Document potential issuances prevented by a CAA record in sufficient detail to provide feedback to the CAB Forum.
• Should dispatch reports of such issuance requests to the contact(s) in the CAA iodef record, if present.
• The CP/CPS section 4.2 disclosure had to state the CA’s policy or practice on processing CAA Records for Fully Qualified Domain Names and clearly specify the set of Issuer Domain Names recognized in CAA issue or issuewild records.

References added

• RFC 6844 was added to the references section.