Ballot SC-099: Improve Recording of Validation Methods

[aarongable]

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 the 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@ 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).

[romanf]

SwissSign supports this change and would endorse.