Discussion Period Begins: Ballot SC-099: Improve Recording of Validation Methods
Aaron Gable
> 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.
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).
- Start time: 2026-04-03 19:00 UTC
- End time: 2026-04-10 19:00 UTC or later
- Start time: TBD
- End time: TBD
Ryan Hurst
The structural changes in this ballot are sound. Moving the recording requirement to Section 5.4.1 and centralizing audit logging requirements where they belong is an obvious improvement. Extending the scope beyond domain and IP validation is also overdue.
Where I part ways is the removal of the BR version number from the logged record.
Ballot 190 passed unanimously in September 2017. It wasn't an abstract exercise in log hygiene. CAs were getting validation wrong, and when the community discovered it, nobody could determine the scope. How many certificates were affected? How far back did the problem go? Which validations needed to be re-performed? Those questions got answered with inference and guesswork because nothing in the CA's records connected a validation event to the rule set the CA believed it was implementing.
The version number solved that in two ways. It gave you a queryable data point for scope assessment after the fact. When a CA discovers their implementation of 3.2.2.4.7 has been non-compliant, the version record narrows the blast radius. You can identify the boundary between "we were running logic we believed complied with version X" and "we updated to comply with version Y." It also served as a forcing function. A CA that keeps an accurate version record has necessarily reviewed the changes and verified their implementation. A CA that hasn't done that work can't accurately log the version. The record is evidence of the process, not just a label.
The ballot argues timestamps are sufficient, but validation methods aren't self-contained. They pull in definitions, DNSSEC requirements, and other sections that can change without the method number changing. An auditor working from a timestamp alone has to independently determine which BR version was in effect, then trace all the dependencies. The version record gives them a bounded starting point. The assumption that auditors will uniformly perform that reconstruction doesn't match how audits have actually worked in this ecosystem.
The ballot also cites CCADB self-assessments as replacing the forcing-function role. But self-assessments verify that a CA claims to have reviewed changes. A version record in the audit log is evidence that deployed systems actually reflect those changes. Attestation and implementation evidence serve different purposes. One doesn't replace the other.
I've watched this pattern repeat more than a few times. Requirements get introduced because something went wrong. They work well enough that the problems they prevent become invisible. Someone proposes removing them because they're operationally inconvenient and the problems feel historical. Eventually the problem recurs. The version logging requirement is exhibiting this exact lifecycle.
The operational concerns are legitimate, but the fix is to clarify the requirement, not remove it. If the BRs stated that the logged version tracks deployed validation logic rather than the publication date of the BR document, the operational burden largely disappears. CAs wouldn't need to flip a version string the instant a new BR is published when their validation logic hasn't changed. The audit value stays intact. And auditors get something concrete to verify against change management records.
I'd support this ballot if it retained the version number with clarified semantics. Removing it takes away a data point that was added for good reason and that we will miss the next time a CA's validation implementation turns out to have been broken for an extended period.
Ryan Hurst
--
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/CAEmnEreM1d7wkxPmg4-_KOF5HwCQ7OcaWKCr%2BmBvMKS%2Bc7O%2BQg%40mail.gmail.com.