Discussion Begins: Ballot SC-098: Process RFC 8657 CAA Parameters
Wayne Thayer
Ballot SC-098: 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 moves and 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 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-02 15:00 UTC
End time: no earlier than 2026-04-09 15:00 UTC
Vote for approval (7 days)
Start time: TBD
End time: TBD
Dimitris Zacharopoulos (HARICA)
As Aaron correct highlighted in this thread, there is some subtlety in the BRs around the mapping between "ca-tbr-7" and "dns-01". I don't think an implementer just reading the BRs can easily come to that conclusion.
Right now, we have the following one-to-one mappings between the BRs and the RFC:
- ca-tbr-19 and http-01
- ca-tbr-20 and tls-alpn-01
It might make sense to first introduce a new domain validation method for DNS-ACME, just like we do for the agreed-upon change to website - ACME (3.2.2.4.19).
Thanks,
Dimitris.
--
You received this message because you are subscribed to the Google Groups "Server Certificate WG (CA/B Forum)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to servercert-w...@groups.cabforum.org.
To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/CAPh8bk-n6kpuRqL3yKK64SQb6w0sBR79WuaLLnd6qNGp5GdU7Q%40mail.gmail.com.