Voting Period Begins: Ballot SC-099: Improve Recording of Validation Methods
189 views
Skip to first unread message
Aaron Gable
Apr 10, 2026, 3:30:33 PM (3 days ago) Apr 10
to server...@groups.cabforum.org
Ballot SC-099: Improve Recording of Validation Methods
This ballot is written by Aaron Gable (ISRG / Let's Encrypt) and endorsed by Gurleen Grewal (Google Trust Services), Trev Ponds-White (Amazon Trust Services), and Roman Fischer (SwissSign).
Summary of the Ballot
Remove ambiguous language from Section 3.2.2.4 and 3.2.2.5 requiring that CAs "record" the "relevant BR version number" when performing validation.
Replace this with unambiguous language in Section 5.4.1, requiring that CAs specifically audit log the information being validated and what validation method they are using to do so.
The new language has an Effective Date of July 15, 2026, giving CAs two months from the expected end of this ballot's IPR period to comply.
Background of the Ballot
The current BRs contain the following text in Sections 3.2.2.4 and 3.2.2.5:
> CAs SHALL maintain a record of which [domain/IP] validation method, including relevant BR version number, they used to validate every [domain/IP Address].
This text is problematic for four reasons:
- it only applies to domains and IP addresses, not other things being validated like organization information;
- the requirement to "maintain a record" is unclear (in audit logs? in a database? in a document?);
- no one is sure what the "relevant BR version" is (the effective version when the validation happened? the version that the validation process believes it implements?); and
- the text is not in Section 5.4.1, which is where the BRs concentrate requirements about recording information.
To resolve these issues, we need to start from first principles. The goal, as evidenced by discussion when this requirement was introduced and recollections of CA/BF members who were participating at the time, is to ensure that CAs and auditors are able to definitively identify the validation process with which the CA was required to comply for any given validation.
To determine what rules governed any given validation, we need two pieces of information:
1. When they performed that validation. The current requirements in Section 5.4.1 already require the CA to audit log the time of every verification procedure.
2. What validation method the CA used. This ballot augments Section 5.4.1 to also require that the CA audit log the validation method used, as well as other useful information.
Because we can accomplish the goal with a small addition to Section 5.4.1, this ballot removes the current text from Sections 3.2.2.4 and 3.2.2.5.
Note that this ballot removes the requirement to "record" the "relevant BR version number". This is not considered a loss, for several reasons:
- No CA or auditor should be relying on a logged BR version number to determine which version of the BRs governed the validation. The logged version number is not enforceable; the only information which can be relied upon to map a validation to a BRs version is the time at which the validation was performed.
- If a new version of the BRs adds requirements to a validation method, but gates those new requirements behind a future effective date, the logged version number may indicate that the CA complies with that new version long before the CA has actually implemented the soon-to-be-required behavior.
- If a new version of the BRs adds requirements to a validation method immediately upon the new version becoming effective, then a CA must update their processes to comply before the new version of the BRs is even published, and therefore the logged version number will be out-of-date compared to the implemented behavior.
- Part of the original motivation behind these statements was to encourage CAs to actually read new versions of the BRs and ensure their processes comply with them. We now have other mechanisms to encourage this behavior, such as CCADB self-assessments.
Therefore we conclude that recording the relevant BRs version number is neither useful nor well-specified, and therefore should not be included in the BRs.
This issue was discussed on Mozilla dev-security-policy@ (https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/x4zRcboSDwU) as well as at the CA/BF Face-to-Face Meeting 67 in Houston on March 10, 2026. The conclusion of those discussions was that we should create this ballot. The discussion period thread for this ballot can be seen here: https://groups.google.com/a/groups.cabforum.org/g/servercert-wg/c/KnkGWHEhWAI/m/juiAtWOJBwAJ
> CAs SHALL maintain a record of which [domain/IP] validation method, including relevant BR version number, they used to validate every [domain/IP Address].
This text is problematic for four reasons:
- it only applies to domains and IP addresses, not other things being validated like organization information;
- the requirement to "maintain a record" is unclear (in audit logs? in a database? in a document?);
- no one is sure what the "relevant BR version" is (the effective version when the validation happened? the version that the validation process believes it implements?); and
- the text is not in Section 5.4.1, which is where the BRs concentrate requirements about recording information.
To resolve these issues, we need to start from first principles. The goal, as evidenced by discussion when this requirement was introduced and recollections of CA/BF members who were participating at the time, is to ensure that CAs and auditors are able to definitively identify the validation process with which the CA was required to comply for any given validation.
To determine what rules governed any given validation, we need two pieces of information:
1. When they performed that validation. The current requirements in Section 5.4.1 already require the CA to audit log the time of every verification procedure.
2. What validation method the CA used. This ballot augments Section 5.4.1 to also require that the CA audit log the validation method used, as well as other useful information.
Because we can accomplish the goal with a small addition to Section 5.4.1, this ballot removes the current text from Sections 3.2.2.4 and 3.2.2.5.
Note that this ballot removes the requirement to "record" the "relevant BR version number". This is not considered a loss, for several reasons:
- No CA or auditor should be relying on a logged BR version number to determine which version of the BRs governed the validation. The logged version number is not enforceable; the only information which can be relied upon to map a validation to a BRs version is the time at which the validation was performed.
- If a new version of the BRs adds requirements to a validation method, but gates those new requirements behind a future effective date, the logged version number may indicate that the CA complies with that new version long before the CA has actually implemented the soon-to-be-required behavior.
- If a new version of the BRs adds requirements to a validation method immediately upon the new version becoming effective, then a CA must update their processes to comply before the new version of the BRs is even published, and therefore the logged version number will be out-of-date compared to the implemented behavior.
- Part of the original motivation behind these statements was to encourage CAs to actually read new versions of the BRs and ensure their processes comply with them. We now have other mechanisms to encourage this behavior, such as CCADB self-assessments.
Therefore we conclude that recording the relevant BRs version number is neither useful nor well-specified, and therefore should not be included in the BRs.
This issue was discussed on Mozilla dev-security-policy@ (https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/x4zRcboSDwU) as well as at the CA/BF Face-to-Face Meeting 67 in Houston on March 10, 2026. The conclusion of those discussions was that we should create this ballot. The discussion period thread for this ballot can be seen here: https://groups.google.com/a/groups.cabforum.org/g/servercert-wg/c/KnkGWHEhWAI/m/juiAtWOJBwAJ
This ballot is written by Aaron Gable (ISRG / Let's Encrypt) and endorsed by Gurleen Grewal (Google Trust Services), Trev Ponds-White (Amazon Trust Services), and Roman Fischer (SwissSign).
--- Motion Begins ---
Modify the "Baseline Requirements for the Issuance and Management of Publicly-Trusted Server Certificates", based on Version 2.2.6, per the following redline:
--- Motion Ends ---
This ballot proposes a Final Maintenance Guideline. The procedure for approval of this ballot is as follows:
Discussion (at least 7 days):
- Start time: 2026-04-03 19:00 UTC
- End time: 2026-04-10 19:00 UTC
Vote for approval (7 days):
- Start time: 2026-04-10 19:30 UTC
- End time: 2026-04-17 19:30 UTC
Pedro FUENTES
Apr 13, 2026, 7:04:42 AM (18 hours ago) Apr 13
to server...@groups.cabforum.org
OISTE votes yes to SC-99
--
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/CAEmnErdDP6maNKvZm6p7ysh%2BrcYvPi%2BhWdzuBDfNb8gmj4RT5w%40mail.gmail.com.
WISeKey SA
Address: Avenue Louis-Casaï 58 | 1216 Cointrin | Switzerland
THIS IS A TRUSTED MAIL: This message is digitally signed with a WISeKey identity. If you get a mail from WISeKey please check the signature to avoid security risks
CONFIDENTIALITY: This email and any files transmitted with it can be confidential and it’s intended solely for the use of the individual or entity to which they are addressed. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. If you have received this email in error please notify the sender
DISCLAIMER: WISeKey does not warrant the accuracy or completeness of this message and does not accept any liability for any errors or omissions herein as this message has been transmitted over a public network. Internet communications cannot be guaranteed to be secure or error-free as information may be intercepted, corrupted, or contain viruses. Attachments to this e-mail are checked for viruses; however, we do not accept any liability for any damage sustained by viruses and therefore you are kindly requested to check for viruses upon receipt.
Tugba ÖZCAN (BILGEM KSM)
Apr 13, 2026, 8:54:07 AM (16 hours ago) Apr 13
to servercert-wg
Kamu SM votes Yes on Ballot SC-099.
Tuğba ÖZCAN
TÜBİTAK BİLGEM
TÜBİTAK BİLGEM
Kamu Sertifikasyon Merkezi/E-İmza Teknolojileri Birim Yöneticisi
Kimden: "'Aaron Gable' via Server Certificate WG (CA/B Forum)" <server...@groups.cabforum.org>
Kime: "servercert-wg" <server...@groups.cabforum.org>
Gönderilenler: 10 Nisan Cuma 2026 22:30:17
Konu: [Servercert-wg] Voting Period Begins: Ballot SC-099: Improve Recording of Validation Methods
Kime: "servercert-wg" <server...@groups.cabforum.org>
Gönderilenler: 10 Nisan Cuma 2026 22:30:17
Konu: [Servercert-wg] Voting Period Begins: Ballot SC-099: Improve Recording of Validation Methods
--
Aaron Gable
Apr 13, 2026, 1:49:50 PM (11 hours ago) Apr 13
to server...@groups.cabforum.org
Let's Encrypt / ISRG votes Yes on Ballot SC-099.
Scott Rea
Apr 13, 2026, 1:52:57 PM (11 hours ago) Apr 13
to server...@groups.cabforum.org
eMudhra Votes YES to Ballot SC-099
From: 'Aaron Gable' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org>
Date: Friday, 10 April 2026 at 2:30 PM
To: server...@groups.cabforum.org <server...@groups.cabforum.org>
Subject: [Servercert-wg] Voting Period Begins: Ballot SC-099: Improve Recording of Validation Methods
Date: Friday, 10 April 2026 at 2:30 PM
To: server...@groups.cabforum.org <server...@groups.cabforum.org>
Subject: [Servercert-wg] Voting Period Begins: Ballot SC-099: Improve Recording of Validation Methods
|
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.
|
--
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/CAEmnErdDP6maNKvZm6p7ysh%2BrcYvPi%2BhWdzuBDfNb8gmj4RT5w%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.
To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/CAEmnErdDP6maNKvZm6p7ysh%2BrcYvPi%2BhWdzuBDfNb8gmj4RT5w%40mail.gmail.com.
Disclaimer: The email and its contents hold confidential information and are intended for the person or entity to which it is addressed. If you are not the intended recipient, please note that any distribution or copying of this email is strictly prohibited
as per Company Policy, you are requested to notify the sender and delete the email and associated attachments with it from your system.
Trevoli Ponds-White
Apr 13, 2026, 2:15:56 PM (11 hours ago) Apr 13
to Server Certificate WG (CA/B Forum)
Amazon Trust Services votes Yes
Ben Wilson
Apr 13, 2026, 3:03:14 PM (10 hours ago) Apr 13
to server...@groups.cabforum.org
Mozilla votes "Yes" on Ballot SC-099.
--
Chad Dandar (cdandar)
Apr 13, 2026, 3:11:35 PM (10 hours ago) Apr 13
to server...@groups.cabforum.org
Cisco votes "Yes" on Ballot SC-099.
Chad Dandar
Cisco
--
Hogeun Yoo
Apr 13, 2026, 8:10:09 PM (5 hours ago) Apr 13
to server...@groups.cabforum.org
NAVER Cloud Trust Services votes "Yes" on Ballot SC-099
Best Regards,
Hogeun Yoo
-----Original Message-----
From: "'Aaron Gable' via Server Certificate WG (CA/B Forum)"<server...@groups.cabforum.org>
--
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/CAEmnErdDP6maNKvZm6p7ysh%2BrcYvPi%2BhWdzuBDfNb8gmj4RT5w%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.
To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/CAEmnErdDP6maNKvZm6p7ysh%2BrcYvPi%2BhWdzuBDfNb8gmj4RT5w%40mail.gmail.com.
黃晟(orca)
Apr 13, 2026, 9:36:28 PM (3 hours ago) Apr 13
to server...@groups.cabforum.org
TWCA votes Yes on Ballot SC-099.
Best,
Sean Huang
Senior PKI Compliance Engineer
TEL：02-2370-8886#728
FAX：02-2388-6720
Email：or...@twca.com.tw
10F., No. 85, Yanping South Road,
Taipei, Taiwan (R.O.C.)
--
Reply all
Reply to author
Forward
0 new messages