Ballot SC-097 (V1): "Sunset all remaining use of SHA-1 signatures in Certificates and CRLs" (cabforum#645)

**Purpose of Ballot SC-097:** This ballot proposes updates to the
Baseline Requirements for the Issuance and Management of
Publicly-Trusted TLS Server Certificates (TLS BRs) to sunset all
remaining use of SHA-1 signatures.

**Background:** Over the years, various sunsets have limited the use of
SHA-1 within the TLS BRs, including:
- [Ballot
118](https://cabforum.org/2014/10/16/ballot-118-sha-1-sunset-passed/)
(2014), which prevented the issuance of any new Subscriber certificates
or Subordinate CA certificates using the SHA-1 signing algorithm.
-
[SC-053](https://cabforum.org/2022/01/26/ballot-sc053-sunset-for-sha-1-ocsp-signing/)
(2022), which prevented delegated OCSP signing using the SHA-1 signing
algorithm.

Despite these sunsets, unexpired and unrevoked Subordinate CA
certificates containing the SHA-1 signature algorithm still exist
([examples](https://docs.google.com/spreadsheets/d/1Fd6U_TB9TEGre_GTruHtaXDjTThqhvmvbX9y_bFFR7Q/edit?gid=76828475#gid=76828475)).
Additionally, Certificate Revocation List (CRL) Distribution Points
disclosed to the CCADB are serving CRLs signed with SHA-1
([examples](https://docs.google.com/spreadsheets/d/1Fd6U_TB9TEGre_GTruHtaXDjTThqhvmvbX9y_bFFR7Q/edit?gid=1653596184#gid=1653596184)).

This ballot is motivated by discussion during the Server Certificate
Working Group Meeting at Face-to-Face 66 [(slide
11](https://drive.google.com/file/d/12QCFfLG6NvGFlnIwU_AVM5mD-tZ4hn89/view?usp=sharing)).

**Scope:** Update Section 7.1.3.2.1 to prohibit all remaining use of the
SHA-1 signature algorithm from appearing in Certificates or status
information responses. As part of this sunset and to promote cyber
hygiene, all unexpired Subordinate CA certificates containing the SHA-1
signature algorithm must be revoked.


This proposal does not prohibit the use of SHA-1 to generate
issuerKeyHash or issuerNameHash values, as currently required by [RFC
5019](https://datatracker.ietf.org/doc/html/rfc5019).

**Justification:** This ballot complements prior efforts within the
CA/Browser Forum to eliminate use of the SHA-1 signature algorithm from
PKI hierarchies adhering to the TLS BRs.

Weaknesses regarding the use of the SHA-1 signature algorithm have been
known for several years. These weaknesses were first
[demonstrated](https://security.googleblog.com/2017/02/announcing-first-sha1-collision.html)
in 2017.

**Benefits of adoption:**
- Promote cyber hygiene.
- Reduce risk of potential collisions due to the inherent weaknesses of
SHA-1, therefore improving security.
- Promote use of modern PKI hierarchies.
- Continuity with other technologies also looking to sunset use of SHA-1
([example](https://www.rfc-editor.org/info/rfc9905))

**Proposed Key Dates:**

- Effective September 15, 2026:
     - Prevent use of SHA-1 in new CRLs 
- CAs must revoke unexpired Subordinate CA Certificates containing the
SHA-1 signature algorithm.

**Proposal Revision History:**
- [Version 1](cabforum#635) (created
against TLS BR Version 2.1.9)
- Version 2 (this version, created against TLS BR Version 2.2.1)

_(Note: See a "doc" version of this preamble
[here](https://docs.google.com/document/d/1T-kg0Jfjxe1ungGHnyamYddbNogJAgqMJvpasfzhVj4/edit?tab=t.0).)_

---------

Co-authored-by: Dimitris Zacharopoulos <dzacharo@users.noreply.github.com>

Author: ryancdickson

docs/BR.md

@@ -1,11 +1,11 @@
 ---
 title: Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates
 
-subtitle: Version 2.2.4
+subtitle: Version 2.2.5
 author:
   - CA/Browser Forum
 
-date: 17-February-2026
+date: 25-February-2026
 
 copyright: |
   Copyright 2026 CA/Browser Forum
@@ -159,6 +159,7 @@ The following Certificate Policy identifiers are reserved for use by CAs to asse
 | 2.2.2    | SC090      | Gradually sunset remaining email-based, phone-based, and 'crossover' validation methods | 2025-11-20 | 2026-01-12                        |
 | 2.2.3    | SC094      | DNSSEC exception in email DCV methods                                                  | 2026-01-15  | 2026-02-16                        |
 | 2.2.4    | SC096      | Carve-out for DNSSEC verification logging requirements                                 | 2026-01-14  | 2026-02-17                        |
+| 2.2.5    | SC097      | Sunset all remaining use of SHA-1 signatures in Certificates and CRLs                  | 2026-02-24  | 2026-02-25                        |
 
 \* Effective Date and Additionally Relevant Compliance Date(s)
 
@@ -229,6 +230,7 @@ The following Certificate Policy identifiers are reserved for use by CAs to asse
 | 2026-03-15     | 4.2.1                     | Domain Name and IP Address validation maximum data reuse period is 200 days.     |
 | 2026-03-15     | 6.3.2                     | Maximum validity period of Subscriber Certificates is 200 days.   |
 | 2026-03-15     | 7.1.2.4                   | CAs MUST NOT use Precertificate Signing CAs to issue Precertificates. CAs MUST NOT issue certificates using the Technically Constrained Precertificate Signing CA Certificate Profile specified in Section 7.1.2.4.    |
+| 2026-09-15     | 7.1.3.2.1                 | Sunset all remaining use of SHA-1 in Certificates and CRLs.   |
 | 2027-03-15     | 3.2.2.4 and 3.2.2.5       | CAs MUST NOT rely on Methods 3.2.2.4.16, 3.2.2.4.17, 3.2.2.5.2, and 3.2.2.5.5 to issue Subscriber Certificates.    |
 | 2027-03-15     | 3.2.2.5.3                 | CAs MUST NOT rely on Method 3.2.2.5.3 to issue Subscriber Certificates.    |
 | 2027-03-15     | 4.2.1                     | Domain Name and IP Address validation maximum data reuse period is 100 days.    |
@@ -3485,7 +3487,7 @@ The CA SHALL use one of the following signature algorithms and encodings. When e
   0500a203020140
   ```
 
-In addition, the CA MAY use the following signature algorithm and encoding if all of the following conditions are met:
+Until 2026-09-15, the CA MAY use the following signature algorithm and encoding if all of the following conditions are met:
 
 * If used within a Certificate, such as the `signatureAlgorithm` field of a Certificate or the `signature` field of a TBSCertificate:
   * The new Certificate is a Root CA Certificate or Subordinate CA Certificate that is a Cross-Certificate; and,
@@ -3510,6 +3512,8 @@ In addition, the CA MAY use the following signature algorithm and encoding if al
   Encoding:
   `300d06092a864886f70d0101050500`
 
+Prior to 2026‐09‐15, the CA SHALL revoke any unexpired Subordinate CA Certificate that contains `RSASSA-PKCS1-v1_5 with SHA-1` within the Certificate.
+
 ##### 7.1.3.2.2 ECDSA
 
 The CA SHALL use the appropriate signature algorithm and encoding based upon the signing key used.