Discussion Period Begins - Ballot SC-092: "Sunset use of Precertificate Signing CAs"
Ryan Dickson
Purpose of Ballot SC-092:
This ballot proposes updates to the Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates (TLS BRs) to sunset use of Precertificate Signing CAs, currently specified in Section 7.1.2.4.
Background:
RFC 6962 (2013) describes the concept of “Precertificate Signing Certificates.” This profile allows for the creation of a dedicated intermediate CA that is technically constrained to only issue Precertificates. A profile for Precertificate Signing Certificates was added to the TLS BRs as a part of SC-062.
Adoption of Precertificate Signing CAs remains low, yet they introduce ongoing complexity. Similarly, RFC 9162 (2021) deprecates Precertificate Signing Certificates and the Precertificate Poison extension.
Justification:
Precertificate Signing CAs introduce complexity, and by extension, risk to the ecosystem for virtually zero practical benefit.
Unnecessary complexity
Signing a Precertificate using a separate, dedicated Precertificate Signing CA, which itself chains up to the Issuing CA responsible for signing Subscriber Certificates, forces the ecosystem to build and maintain complex and distinct logic to validate two different types of certificate chains. Prohibiting this profile simplifies X.509 chain validation logic for all parties and allows for convergence reducing the ecosystem's overall attack surface.
They require adopting CA Owners to stand up additional CA infrastructure with very specific requirements on what can be issued from them. This introduces new points of failure and maintenance burden.
They make it difficult for Certificate Transparency Monitors and other ecosystem observers to get a comprehensive view of certificate issuance.
Source of real-world critical failure
The complexity of supporting this alternate chain-building mechanism can contribute directly to severe operational failures, recently resulting in the rejection of a CT log.
Negligible adoption
With only 2 publicly-trusted CA Owners currently using Precertificate Signing CAs, the entire global ecosystem is being forced to bear the cost and risk of supporting a complex mechanism that serves no practical purpose for a majority of the internet.
Discussion at the 11 September SCWG meeting described Precertificate Signing CAs as a rarely used option that does not interact nicely with other parts of the ecosystem.
Benefits of adoption
Promote simplicity.
Reduce attack surface.
Proposed Key Dates:
The effective date considered in this update is intended to allow CA Owners relying on existing Precertificate Signing CAs to transition to alternatives.
Effective March 15, 2026:
The Certificate Profile specified in Section 7.1.2.4 MUST NOT be used to issue new certificates.
Existing Precertificate Signing CAs MUST NOT be used to issue new Precertificates.
Proposal Revision History:
Pre-ballot: Some discussion found in this GitHub Pull Request. Feedback ultimately incorporated into Version 1 (this version) of the ballot.
Version #1 Ballot and discussion (initiated via this email, see "redline" below)
The following motion has been proposed by Ryan Dickson and Chris Clements of Google (Chrome Root Program) and endorsed by Aaron Gable (Internet Security Research Group) and Clint Wilson (Apple).
— 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.1.7.
MODIFY the Baseline Requirements as specified in the following Redline:
— Motion Ends —
This ballot proposes a Final Maintenance Guideline. The procedure for approval of this ballot is as follows:
Discussion (no less than 7 days)
Start: 2025-09-18 13:30:00 ET
End no earlier than: 2025-09-25 13:30:00 ET
Vote for approval (7 days)
Start: TBD
End: TBD
Roman Fischer
Dear Ryan,
Your reference to RFC 9162 confuses me a bit: The redline does not contain anything else than deprecating 7.1.2.4.
Am I correct in assuming that the reference to RFC 9162 is for illustration only and the ballot isn't proposing any other changes to pre-certificates (RFC 9162 mentions e.g. the removal of the percertificate poison…)?
Thanks
Roman
--
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/CADEW5O-hB5bunGNs6nyfntmMoSVHUk2Ku-wiwTbzZ-PKGa-Adw%40mail.gmail.com.
Ryan Dickson
Am I correct in assuming that the reference to RFC 9162 is for illustration only and the ballot isn't proposing any other changes to pre-certificates (RFC 9162 mentions e.g. the removal of the percertificate poison…)?
Jeun, Inkyung (Lynn)
Visa votes YES on SC-092.
Thanks,
Lynn.
From: 'Ryan Dickson' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org>
Sent: Thursday, September 18, 2025 1:29 PM
To: server...@groups.cabforum.org
Subject: [Servercert-wg] Discussion Period Begins - Ballot SC-092: "Sunset use of Precertificate Signing CAs"
Purpose of Ballot SC-092:
--