Voting 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: 2025-09-25 15:29:59 ET
Vote for approval (7 days)
Start: 2025-09-25 15:30:00 ET
End: 2025-10-02 15:30:00 ET
Ben Wilson
--
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-0E4LPTFJHC90j-N6JE7UL-E7iX-Ts6qdYH5tDce-s1Q%40mail.gmail.com.
Pedro FUENTES
WISeKey SA
蔡家宏(chtsai)
TWCA votes 'Yes' on ballot SC-092.
蔡家宏 Chya-Hung Tsai
Director
Identification & Certificate Research
Tel: +886-2-2370-8886 ext. 722
Fax: +886-2-2388-6720
Email: cht...@twca.com.tw
10F., No. 85, Yanping South Road,
Taipei 100002, Taiwan(R.O.C.)
https://www.twca.com.tw
From: 'Ryan Dickson' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org>
Sent: Friday, September 26, 2025 3:29 AM
To: server...@groups.cabforum.org
Subject: [Servercert-wg] Voting Period Begins - Ballot SC-092: "Sunset use of Precertificate Signing CAs"
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
o 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.
o 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.
o 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
o 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
o 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.
o 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:
o The Certificate Profile specified in Section 7.1.2.4 MUST NOT be used to issue new certificates.
o 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: 2025-09-25 15:29:59 ET
Vote for approval (7 days)
· Start: 2025-09-25 15:30:00 ET
· End: 2025-10-02 15:30:00 ET
--
Nome Huang
Clint Wilson
Tim Hollebeek
DigiCert votes YES on SC-092.
-Tim
From: 'Ryan Dickson' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org>
Sent: Thursday, September 25, 2025 3:29 PM
To: server...@groups.cabforum.org
Subject: [Servercert-wg] Voting Period Begins - Ballot SC-092: "Sunset use of Precertificate Signing CAs"
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
o 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.
o 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.
o 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
o 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
o 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.
o 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:
o The Certificate Profile specified in Section 7.1.2.4 MUST NOT be used to issue new certificates.
o 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: 2025-09-25 15:29:59 ET
Vote for approval (7 days)
· Start: 2025-09-25 15:30:00 ET
· End: 2025-10-02 15:30:00 ET
--
Wayne Thayer
--
Chris Clements
陳立群
— 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: 2025-09-25 15:29:59 ET
Vote for approval (7 days)
Start: 2025-09-25 15:30:00 ET
End: 2025-10-02 15:30:00 ET
--
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-0E4LPTFJHC90j-N6JE7UL-E7iX-Ts6qdYH5tDce-s1Q%40mail.gmail.com.
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.
本信件可能包含中華電信股份有限公司機密資訊,非指定之收件者,請勿蒐集、處理或利用本信件內容,並請銷毀此信件. 如為指定收件者,應確實保護郵件中本公司之營業機密及個人資料,不得任意傳佈或揭露,並應自行確認本郵件之附檔與超連結之安全性,以共同善盡資訊安全與個資保護責任.
Please be advised that this email message (including any attachments) contains confidential information and may be legally privileged. If you are not the intended recipient, please destroy this message and all attachments from your system and do not further collect, process, or use them. Chunghwa Telecom and all its subsidiaries and associated companies shall not be liable for the improper or incomplete transmission of the information contained in this email nor for any delay in its receipt or damage to your system. If you are the intended recipient, please protect the confidential and/or personal information contained in this email with due care. Any unauthorized use, disclosure or distribution of this message in whole or in part is strictly prohibited. Also, please self-inspect attachments and hyperlinks contained in this email to ensure the information security and to protect personal information.
Doug Beattie
GlobalSign votes "Yes" for Ballot SC-092
Doug
From: 'Ryan Dickson' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org>
Sent: Thursday, September 25, 2025 3:29 PM
To: server...@groups.cabforum.org
Subject: [Servercert-wg] Voting Period Begins - Ballot SC-092: "Sunset use of Precertificate Signing CAs"
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
o 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.
o 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.
o 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
o 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
o 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.
o 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:
o The Certificate Profile specified in Section 7.1.2.4 MUST NOT be used to issue new certificates.
o 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: 2025-09-25 15:29:59 ET
Vote for approval (7 days)
· Start: 2025-09-25 15:30:00 ET
· End: 2025-10-02 15:30:00 ET
--
Hogeun Yoo
-----Original Message-----
From: "'Ryan Dickson' via Server Certificate WG (CA/B Forum)"<server...@groups.cabforum.org>
To: <server...@groups.cabforum.org>;
Cc:
Sent: 2025. 9. 26. (금) 04:29 (GMT+09:00)
Subject: [Servercert-wg] Voting Period Begins - Ballot SC-092: "Sunset use of Precertificate Signing CAs"
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-0E4LPTFJHC90j-N6JE7UL-E7iX-Ts6qdYH5tDce-s1Q%40mail.gmail.com.
Dimitris Zacharopoulos (HARICA)
--
Adriano Santoni
ACTALIS votes "yes" to ballot SC092.
Adriano
--
Marco Schambach
IdenTrust votes “Yes” for Ballot SC-092
Marco S.
TrustID Program Manager
From: 'Ryan Dickson' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org>
Sent: Thursday, September 25, 2025 3:29 PM
To: server...@groups.cabforum.org
Subject: [External][Servercert-wg] Voting Period Begins - Ballot SC-092: "Sunset use of Precertificate Signing CAs"
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
o 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.
o 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.
o 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
o 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
o 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.
o 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:
o The Certificate Profile specified in Section 7.1.2.4 MUST NOT be used to issue new certificates.
o 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: 2025-09-25 15:29:59 ET
Vote for approval (7 days)
· Start: 2025-09-25 15:30:00 ET
· End: 2025-10-02 15:30:00 ET
--
Scott Rea
eMudhra votes YES on Ballot SC-092
From:
'Ryan Dickson' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org>
Date: Thursday, 25 September 2025 at 1:30 PM
To: server...@groups.cabforum.org <server...@groups.cabforum.org>
Subject: [Servercert-wg] Voting Period Begins - Ballot SC-092: "Sunset use of Precertificate Signing CAs"
|
CAUTION: This email is originated from outside of the organization. Do not open the links or the attachments unless you recognize the sender and know the content is safe. |
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
o 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.
o 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.
o 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
o 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
o 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.
o 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:
o The Certificate Profile specified in Section 7.1.2.4 MUST NOT be used to issue new certificates.
o 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: 2025-09-25 15:29:59 ET
Vote for approval (7 days)
· Start: 2025-09-25 15:30:00 ET
· End: 2025-10-02 15:30:00 ET
--
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-0E4LPTFJHC90j-N6JE7UL-E7iX-Ts6qdYH5tDce-s1Q%40mail.gmail.com.
Martijn Katerbarg
Date: Thursday, 25 September 2025 at 21:31
To: server...@groups.cabforum.org <server...@groups.cabforum.org>
Subject: [Servercert-wg] Voting Period Begins - Ballot SC-092: "Sunset use of Precertificate Signing CAs"
sde...@godaddy.com
Date: Thursday, September 25, 2025 at 3:30 PM
To: server...@groups.cabforum.org <server...@groups.cabforum.org>
Subject: [Servercert-wg] Voting Period Begins - Ballot SC-092: "Sunset use of Precertificate Signing CAs"
Purpose of Ballot SC-092:
Aaron Gable
--
성지은 Jieun Seong
Date: 2025/09/26 04:39:07
From: "'Ryan Dickson' via Server Certificate WG (CA/B Forum)"
To: server...@groups.cabforum.org
Subject: [Servercert-wg] Voting Period Begins - Ballot SC-092: "Sunset use of Precertificate Signing CAs"
--
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-0E4LPTFJHC90j-N6JE7UL-E7iX-Ts6qdYH5tDce-s1Q%40mail.gmail.com.
qi_ji...@itrus.com.cn
Date: 2025-09-26 03:29To: servercert-wgSubject: [Servercert-wg] Voting Period Begins - Ballot SC-092: "Sunset use of Precertificate Signing CAs"
Purpose of Ballot SC-092:
--
Peter Miškovič
Disig votes „YES“ on Ballot SC-092: "Sunset use of Precertificate Signing CAs".
Regards
Peter Miskovic
From: 'Ryan Dickson' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org>
Sent: štvrtok 25. septembra 2025 21:29
To: server...@groups.cabforum.org
Subject: [Servercert-wg] Voting Period Begins - Ballot SC-092: "Sunset use of Precertificate Signing CAs"
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
o 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.
o 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.
o 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
o 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
o 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.
o 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:
o The Certificate Profile specified in Section 7.1.2.4 MUST NOT be used to issue new certificates.
o 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: 2025-09-25 15:29:59 ET
Vote for approval (7 days)
· Start: 2025-09-25 15:30:00 ET
· End: 2025-10-02 15:30:00 ET
--
Backman, Antti
Telia votes ’Yes’ on Ballot SC-092
//Antti
From: 'Ryan Dickson' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org>
Date: Thursday, 25. September 2025 at 22.30
To: server...@groups.cabforum.org <server...@groups.cabforum.org>
Subject: [Servercert-wg] Voting Period Begins - Ballot SC-092: "Sunset use of Precertificate Signing CAs"
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
o 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.
o 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.
o 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
o 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
o 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.
o 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:
o The Certificate Profile specified in Section 7.1.2.4 MUST NOT be used to issue new certificates.
o 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: 2025-09-25 15:29:59 ET
Vote for approval (7 days)
· Start: 2025-09-25 15:30:00 ET
· End: 2025-10-02 15:30:00 ET
--
Kateryna Aleksieieva
Certum votes YES on Ballot SC-092
Kind regards,
Kateryna Aleksieieva
From: 'Ryan Dickson' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org>
Sent: Thursday, September 25, 2025 9:29 PM
To: server...@groups.cabforum.org
Subject: [Servercert-wg] Voting Period Begins - Ballot SC-092: "Sunset use of Precertificate Signing CAs"
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
o 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.
o 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.
o 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
o 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
o 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.
o 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:
o The Certificate Profile specified in Section 7.1.2.4 MUST NOT be used to issue new certificates.
o 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: 2025-09-25 15:29:59 ET
Vote for approval (7 days)
· Start: 2025-09-25 15:30:00 ET
· End: 2025-10-02 15:30:00 ET
--
Alvin Wang
大野 文彰
SECOM Trust Systems votes YES on Ballot SC-092.
Best regards,
ONO Fumiaki / 大野 文彰
SECOM Trust Systems CO., LTD.
(Japanese name order: family name first, in uppercase)
From: 'Ryan Dickson' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org>
Sent: Friday, September 26, 2025 4:29 AM
To: server...@groups.cabforum.org
Subject: [Servercert-wg] Voting Period Begins - Ballot SC-092: "Sunset use of Precertificate Signing CAs"
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
o 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.
o 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.
o 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
o 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
o 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.
o 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:
o The Certificate Profile specified in Section 7.1.2.4 MUST NOT be used to issue new certificates.
o 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: 2025-09-25 15:29:59 ET
Vote for approval (7 days)
· Start: 2025-09-25 15:30:00 ET
· End: 2025-10-02 15:30:00 ET
--
Romain DELVAL
Certigna votes "Yes" for Ballot SC-092.
Romain DELVAL
De : 'Ryan Dickson' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org>
Envoyé : jeudi 25 septembre 2025 21:29
À : server...@groups.cabforum.org
Objet : [Servercert-wg] Voting Period Begins - Ballot SC-092: "Sunset use of Precertificate Signing CAs"
⚠ FR : Ce message provient de l'extérieur de l'organisation. N'ouvrez pas de liens ou de pièces jointes à moins que vous ne sachiez que le contenu est fiable. ⚠
Yoshihiko Matsuo
Yoshihiko Matsuo(JPRS)
On Thu, 25 Sep 2025 15:29:00 -0400
"'Ryan Dickson' via Server Certificate WG (CA/B Forum)" <server...@groups.cabforum.org> wrote:
> 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:
>
>
> Adoption of Precertificate Signing CAs remains low, yet they introduce ongoing complexity. Similarly,?<https://datatracker.ietf.org/doc/html/rfc9162>RFC 9162?(2021)?<https://datatracker.ietf.org/doc/html/rfc9162#name-major-differences-from-ct-1>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
>
> Source of real-world critical failure
>
> Negligible adoption
> With only <https://groups.google.com/a/chromium.org/g/ct-policy/c/87iKRKn8WpE/m/TaOJUjDVAwAJ>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.?
>
> 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:
>
> Proposal Revision History:
>
>
> 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).
>
>
>
> 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:
>
>
> https://github.com/cabforum/servercert/compare/b6a014d4aee244c019ef6ca41667045cdbfefb81..d0c9842bca6f912c31bd9c28f6cb3be3e6d91010
>
>
>
> 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: 2025-09-25 15:29:59 ET
>
>
> Vote for approval (7 days)
> Start: 2025-09-25 15:30:00 ET
> End: 2025-10-02 15:30:00 ET
>
>
> --
> 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.
Janet Hines
VikingCloud votes YES on Ballot SC-092.
From: 'Ryan Dickson' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org>
Date: Thursday, September 25, 2025 at 3:30 PM
To: server...@groups.cabforum.org <server...@groups.cabforum.org>
Subject: [Servercert-wg] Voting Period Begins - Ballot SC-092: "Sunset use of Precertificate Signing CAs"
Caution: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
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
o 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.
o 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.
o 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
o 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
o 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.
o 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:
o The Certificate Profile specified in Section 7.1.2.4 MUST NOT be used to issue new certificates.
o 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: 2025-09-25 15:29:59 ET
Vote for approval (7 days)
· Start: 2025-09-25 15:30:00 ET
· End: 2025-10-02 15:30:00 ET
--
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.
Company Registration Details
VikingCloud is the registered business name of Sysxnet Limited. Sysxnet Limited is registered in Ireland under company registration number 147176 and its registered office is at 1st Floor, Block 71a, The Plaza, Park West Business Park, Dublin 12, Ireland.
Email Disclaimer
The information contained in this communication is intended solely for the use of the individual or entity to whom it is addressed and others authorized to receive it. It may contain confidential or legally privileged information. If you are not the intended
recipient you are hereby notified that any disclosure, copying, distribution or taking any action in reliance on the contents of this information is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us
immediately by responding to this email and then delete it from your system. Sysxnet Limited is neither liable for the proper and complete transmission of the information contained in this communication nor for any delay in its receipt..
jun....@cybertrust.co.jp
-----Original Message-----
From: 'Ryan Dickson' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org>
Subject: [Servercert-wg] Voting Period Begins - Ballot SC-092: "Sunset use of Precertificate Signing CAs"
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:
Adoption of Precertificate Signing CAs remains low, yet they introduce ongoing complexity. Similarly, RFC 9162 <https://datatracker.ietf.org/doc/html/rfc9162> (2021) deprecates <https://datatracker.ietf.org/doc/html/rfc9162#name-major-differences-from-ct-1> 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.
* 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 <https://issues.chromium.org/issues/437003344#comment13> of a CT log.
* Negligible adoption
* With only 2 <https://groups.google.com/a/chromium.org/g/ct-policy/c/87iKRKn8WpE/m/TaOJUjDVAwAJ> 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.
* 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 <https://github.com/cabforum/servercert/pull/615> 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).
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:
https://github.com/cabforum/servercert/compare/b6a014d4aee244c019ef6ca41667045cdbfefb81..d0c9842bca6f912c31bd9c28f6cb3be3e6d91010
This ballot proposes a Final Maintenance Guideline. The procedure for approval of this ballot is as follows:
Discussion (no less than 7 days)
* End: 2025-09-25 15:29:59 ET
Vote for approval (7 days)
* End: 2025-10-02 15:30:00 ET
--
You received this message because you are subscribed to the Google Groups "Server Certificate WG (CA/B Forum)" group.
To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/CADEW5O-0E4LPTFJHC90j-N6JE7UL-E7iX-Ts6qdYH5tDce-s1Q%40mail.gmail.com <https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/CADEW5O-0E4LPTFJHC90j-N6JE7UL-E7iX-Ts6qdYH5tDce-s1Q%40mail.gmail.com?utm_medium=email&utm_source=footer> .
Dimitris Zacharopoulos (HARICA)
According to the Forum's records, Cybertrust Japan has not listed you as
a voting representative so we can't count this vote until it is
submitted by the authorized voting representative (Maiko Ishibashi).
Thank you,
Dimitris Zacharopoulos
--
Dimitris Zacharopoulos
CA/B Forum SCWG Chair
maiko.i...@cybertrust.co.jp
Thank you for letting us know about the voting representative.
Again, Cybertrust Japan votes YES on Ballot SC-092.
Regards,
Maiko ISHIBASHI
Cybertrust Japan Co.,Ltd.
Entschew, Enrico
D-Trust votes „YES“ on Ballot SC-092.
Thanks,
Enrico
Von: 'Ryan Dickson' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org>
Gesendet: Donnerstag, 25. September 2025 21:29
An: server...@groups.cabforum.org
Betreff: [Servercert-wg] Voting Period Begins - Ballot SC-092: "Sunset use of Precertificate Signing CAs"
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
o 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.
o 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.
o 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
o 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
o 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.
o 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:
o The Certificate Profile specified in Section 7.1.2.4 MUST NOT be used to issue new certificates.
o 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: 2025-09-25 15:29:59 ET
Vote for approval (7 days)
· Start: 2025-09-25 15:30:00 ET
· End: 2025-10-02 15:30:00 ET
--
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-0E4LPTFJHC90j-N6JE7UL-E7iX-Ts6qdYH5tDce-s1Q%40mail.gmail.com.
Fernandez Ruperez, David Alvaro
Izenpe votes “YES” on Ballot SC-092