Discussion Begins: Ballot SC-098v2: Process RFC 8657 CAA Parameters Inbox
Wayne Thayer
A number of suggestions have been made and adopted in version 2 of this ballot, including:
An allowance for ACME CAs to recognize “parent” accounts that authorize multiple ACME accounts
Clarifications for applicability to ACME and non-ACME implementations
Case sensitivity requirements
Using a more appropriate example of equivalence between ACME and non-ACME methods.
A few other suggestions were discussed during a recent Validation subcommittee call and rejected via consensus. Thank you to everyone who contributed to these improvements. I believe that this ballot is ready to start another discussion period.
Discussion Begins: Ballot SC-098v2: Process RFC 8657 CAA Parameters
Summary of the Ballot
This ballot adds the requirement that CAs process the Certification Authority Authorization (CAA) parameters defined in RFC 8657. These parameters allow the issuance policy specified by a CAA record to include the account and domain validation methods that may be used to issue a certificate for the subject domain.
The ballot defines a syntax for specifying non-ACME domain validation methods in section 4.2.2.1.3.
CAs supporting non-ACME accounts must document the accepted accounturi format in their CP or CPS.
These requirements take effect on March 15, 2027.
The ballot also consolidates CAA requirements into section 4.2.1.
Summary of Discussion
This ballot has undergone extensive discussion in the Validation Working Group dating back to 2024, and in https://github.com/cabforum/servercert/pull/567.
The full value of the CAA extensions defined in RFC 8657 will only be realized if CAs process the parameters rather than ignoring them.
We originally considered including DNSSEC requirements in this ballot but decided to separate them into ballot SC-085.
Consensus formed that Non-ACME validation methods must use a specific syntax to avoid conflicts and provide consistency across CAs.
Special thanks to Grace Cimaszewski for helping to move this ballot forward.
The following motion has been proposed by Wayne Thayer (Fastly) and endorsed by Chris Clements (Google) and Ben Wilson (Mozilla).
--- Motion Begins ---
This ballot modifies the “Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates” (“Baseline Requirements”), based on Version 2.2.6
--- Motion Ends ---
This ballot proposes a Final Maintenance Guideline. The procedure for approval of this ballot is as follows:
Discussion (at least 7 days)
Start time: 2026-04-27 00:00 UTC
End time: no earlier than 2026-05-04 00:00 UTC
Vote for approval (7 days)
Start time: TBD
End time: TBD