Ballot SC-0XX - Sunset all remaining use of SHA-1

[ryancdickson]

Notes:

• Opening this initial Pull Request to collect feedback on a draft ballot.
• A "doc" version of this preamble is available here.
• I accidentally closed a previous version of this PR when trying to rename the branch (Sorry!)

---

Purpose of Ballot SC-XX: 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 (2014), which prevented the issuance of any new Subscriber certificates or Subordinate CA certificates using the SHA-1 signing algorithm.
• SC-053 (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). Additionally, Certificate Revocation List (CRL) Distribution Points disclosed to the CCADB are serving CRLs signed with SHA-1 (examples).

This ballot is motivated by discussion during the Server Certificate Working Group Meeting at Face-to-Face 66 (slide 11).

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.

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 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.

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.

[ryancdickson]

As a point of clarification, this proposal does not prohibit the use of SHA-1 to generate issuerKeyHash or issuerNameHash values, as currently required by RFC 5019:

“Clients MUST use SHA1 as the hashing algorithm for the CertID.issuerNameHash and the CertID.issuerKeyHash values.”

It is worth noting that draft-ietf-lamps-rfc5019bis-12 updates RFC 5019 to require SHA-256 for these values. Updating the TLS BRs to reference this new standard would help further move the ecosystem away from SHA-1 (see #614).

While that is outside the scope of this specific ballot, we would be supportive of a separate ballot to move that forward. It seems like it would be a great "starter" ballot for another member of the community looking to become more involved in the balloting process.