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/CAEmnErfxuRye7TmhTOLHx1n_BWJX9rodzBhNpFEkJnczF69g%2Bw%40mail.gmail.com.
