Home » All CA/Browser Forum Posts » Ballot SC044: Clarify Acceptable Status Codes

Ballot SC044: Clarify Acceptable Status Codes

The voting on ballot SC44 has completed, and the ballot has passed.

Voting Results

Certificate Issuers

21 votes total, with no abstentions

· 21 Yes votes: Buypass, Certum (Asseco), Chunghwa Telecom, D-TRUST, DigiCert, eMudhra, Entrust, Firmaprofesional, GlobalSign, GoDaddy, HARICA, Kamu SM, Let’s Encrypt / ISRG, OISTE, Sectigo, SSL.com, SwissSign, Telia Company, TrustCor, SecureTrust, Visa

· 0 No Votes

· 0 Abstentions

Certificate Consumers

5 votes total, with no abstentions

5 Yes votes: Apple, Cisco, Google, Microsoft, Mozilla
0 No votes
0 Abstentions

Bylaw Requirements

Bylaw 2.3(f) requires:

o A “yes” vote by two-thirds of Certificate Issuer votes and by 50%-plus-one of Certificate Consumer votes. Votes to abstain are not counted for this purpose. This requirement was MET for Certificate Issuers and MET for Certificate Consumers.

o at least one Certificate Issuer and one Certificate Consumer Member must vote in favor of a ballot for the ballot to be adopted. This requirement was MET.

Bylaw 2.3(g) requires that a ballot result only be considered valid when “more than half of the number of currently active Members has participated”. Votes to abstain are counted in determining quorum. Half of the currently active members at the start of voting was 12, so the quorum was 13 for this ballot. This requirement was MET.

This ballot now enters the IP Rights Review Period to permit members to review the ballot for relevant IP rights issues.

Ballot Text

Purpose of Ballot:

This ballot clarifies the allowed HTTP status codes used for following redirects in domain validation methods 18 and 19, and specifies that the target URI must come from the final value of the Location response header.

The following motion has been proposed by Niko Carpenter of SecureTrust and endorsed by Corey Bonnell of DigiCert and Ryan Sleevi of Google.

–MOTION BEGINS–

This ballot modifies the “Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates” as defined in the following redline, based on Version 1.7.4:

https://github.com/cabforum/servercert/compare/9672b03bec91ad9a80f826e928e47f5c1f82964b..bf726440a1da70262f1cf51c9d88d9dd0e903bf5

–MOTION ENDS–

This ballot proposes a Final Maintenance Guideline.

The procedure for approval of this ballot is as follows:

Discussion (7+ days)

Start Time: 16-April 2021 15:30 UTC

End Time: 23-April 2021 19:30 UTC

Vote for approval (7 days)

Start Time: 23-April 2021 19:30 UTC

End Time: 30-April 2021 19:30 UTC

Latest releases

Server Certificate Requirements
SC095v3: Clean-up 2025 - Apr 2, 2026

Code Signing Requirements
v3.8 - Aug 5, 2024

What’s Changed CSC-25: Import EV Guidelines to CS Baseline Requirements by @dzacharo in https://github.com/cabforum/code-signing/pull/38 Full Changelog: https://github.com/cabforum/code-signing/compare/v3.7...v3.8

S/MIME Requirements
v1.0.14 - Ballot SMC016 - May 5, 2026

This ballot maintains consistency between the S/MIME Baseline Requirements and the TLS Baseline Requirements with changes introduced by Ballots SC096 and SC097. Specifically, this ballot: Creates a carve-out of the logging requirements for DNSSEC specifically, stating these are not in scope. For audit purposes, change management logging is able to confirm if the appropriate controls are in effect or not. Sunsets all remaining use of SHA-1 signatures in Certificates and CRLs. It is noted that most uses of SHA-1 signatures are already deprecated by SC097. With this ballot, all unexpired Subordinate CA Certificates issuing S/MIME 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. Includes minor formatting corrections.

Network and Certificate System Security Requirements
Version 2.0.5 (Ballot NS-008) - Jul 9, 2025