The timestamp consistency argument makes me uncomfortable. Applied broadly, it would justify removing every discrete data point the BRs require CAs to log, since auditors can always work backwards from a timestamp and a changelog.
On the DNSSEC example, a version stamp gives an auditor a bounded and deterministic starting point. They know exactly which two document versions to compare and can verify the CA's behavior against that specific set of changes. Without it, they first have to determine which version was in effect at the moment of validation, which is exactly the problem this thread started with: effective dates without times, timezone ambiguity, publication lag. That reconstruction has to happen for every validation event they want to scrutinize, and it has to happen with the same ambiguity CAs were dealing with operationally. It also assumes that the auditors would do that uniformly across the auditor set is a significant assumption that does not seem to align with the depth we have seen auditors apply historically. The reality is that the history of this ecosystem is not short on examples where compliance gaps were visible in the record, long before anyone acted on them. We should be cautious about removing data points that can prompt harder questions. If the logged version should reflect deployed validation logic rather than publication date, say that in the BRs. That addresses the operational concern Gurleen raised, keeps the audit value intact, and gives auditors something concrete to push on. That's the fix worth pursuing. Ryan On Monday, February 23, 2026 at 9:20:32 AM UTC-8 Aaron Gable wrote: > On Mon, Feb 23, 2026 at 8:42 AM Ryan Hurst <[email protected]> wrote: > >> Remove it, and an auditor reconstructing what rules governed a validation >> event has to work from a timestamp and inference rather than a recorded >> fact. That's a meaningful loss of audit fidelity. >> > > Auditors have to work from timestamps for literally all other records, > including certificate issuance itself. CAs are not required to record the > BRs version and certificate profile subsection every time they issue a > certificate, but the Section 7.x.y profiles are just as likely to change in > the middle of an audit cycle as validation methods are -- maybe even more > so. The purpose of the BRs is to ensure that validation and issuance are > secure and trustworthy, not to ensure that an auditor jumps through one > fewer hoops in one particular circumstance. > > And even if we do want to make the auditor's job easier in this way, it's > not clear that recording a BRs version number actually accomplishes that > goal. As you noted, there are many other subsections wrapped up in any > given validation, including definitions, audit logging requirements, DNSSEC > requirements, and more. If the DNSSEC requirements change, but a CA is > still recording a BRs version number from before that change (because the > validation method itself didn't change!), the auditor will have to do > *more* work to realize from the timestamp that DNSSEC needed to be > validated and then check to see if that happened. > > This is what prompted me to propose that we remove the requirement > entirely. I don't think it makes audits easier, and in fact I think it in > practice makes audits harder. It is better for *all* logs to be evaluated > solely based on their timestamp, not on some other claimed BRs version. > This requirement should be removed for the sake of consistency with all > other logs and records. > > Aaron > -- You received this message because you are subscribed to the Google Groups "[email protected]" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/6155d655-141d-42db-9eda-f8a57aaf9bb0n%40mozilla.org.
