I realize this thread has gone quiet, but I wanted to add some context that I now realize I was taking for granted that others may not have remembered, especially since not everyone here was active in the community when this requirement was introduced.
Ballot 190 ( https://cabforum.org/2017/09/19/ballot-190-revised-validation-requirements/) passed unanimously in September 2017. The version number requirement was a direct response to a specific problem that kept coming up. *CAs believed their validation logic was correct and compliant, and when the community or an auditor concluded otherwise, nobody could determine which certificates had been issued using validation that didn't meet the requirements, how far back the problem went, or how many certificates needed to be revoked and reissued.* It was introduced with two fundamental goals. 1. To make that scope assessment possible after the fact. Without a record of which method and which version governed each validation event, those questions got answered with inference and guesswork. 2. To act as a forcing function. A CA that keeps an accurate version record has had to actually review BR changes and verify its implementation against them. A CA that hasn't done that can't accurately log the version. The record is evidence of the process, not just a label. My earlier interpretation of "used" as referring to deployed logic rather than publication date stems directly from this history. SInce the goal was scope assessment and process verification, then "used" has to mean the logic that actually ran, not the version that happened to be current on the calendar. Which brings us back to what raised this thread in the first place. Discovering that your version logging is out of sync with what you are issuing would not normally be something I would expect to trigger a stop issuance. Your change management process would serve as a mitigating control, capturing that you did in fact deploy the right validation logic. I would expect a CA to stop issuance only if they discovered they were actually running the wrong code, and to roll out the logging fix separately when it was safe to do so. Ryan On Monday, February 23, 2026 at 12:40:55 PM UTC-8 Ryan Hurst wrote: > The pressure in this thread is the same pressure that shows up repeatedly > in this ecosystem, reduce specificity in the name of operational > efficiency. Sometimes that pressure is legitimate. Sometimes the > requirement being relaxed is genuinely redundant. But the cumulative effect > of that pattern will be an environment where it will be progressively > harder to audit and a CA ecosystem that is progressively less accountable. > > That would not matter much if our audit regime were more robust than it is > today. WebTrust and ETSI audits are point-in-time, documentation-focused > engagements that rarely involve deep technical inspection of deployed > systems. Root programs have had to step in repeatedly because clean audit > opinions were not reflecting operational reality. That is not a criticism > of auditors individually, it is a structural problem. > > Ultimately, this is a decision root programs will have to make. Optimize > for CA operational flexibility and trust that CAs will make the right call, > or optimize for accountability by preserving the signals that give auditors > something concrete to work with. Removing requirements like this one makes > the first choice easier. It makes the second choice harder. We should at > least be clear that is the tradeoff we are making. > > Ryan > > On Mon, Feb 23, 2026 at 11:21 AM 'Trevoli Ponds-White' via > [email protected] <[email protected]> wrote: > >> I agree Aaron, I also want to make sure we are focusing on operational >> and security outcomes. Not audit optimization driven ones. This is why I >> proposed we update that requirement to be more clear. I’m not also opposed >> to removing it given that we are now being more aggressive at deprecating >> methods. If I recall another reason we wanted to add that was so that we >> would have the ability to understand how much which validation methods are >> used to help understand impact of deprecation. Its not actually clear to me >> how you could reasonably issue a cert without knowing it’s validation >> method so requiring this may be moot. >> >> >> On Monday, February 23, 2026 at 10:35:00 AM UTC-8 Aaron Gable wrote: >> >>> On Mon, Feb 23, 2026 at 9:42 AM Ryan Hurst <[email protected]> wrote: >>> >>>> 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. >>>> >>> Sure, but I'm not talking about applying this broadly, and I'm not >>> talking about reducing the CA's requirement to log *what* they do. I'm >>> talking specifically about recording a specific piece of information which >>> is at best redundant and at worst contradictory. That objection is to a >>> strawman, not to the argument I'm making. >>> >>> We have a direct statement from a root program representative above >>> saying that the point of this requirement is outcome-oriented: "for each >>> validation event, the CA must be able to determine which validation method >>> and which BR version governed that validation.". That's possible entirely >>> with timestamps, just as it is possible to map issuance events to BR >>> versions solely using timestamps. >>> >>>> 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. >>>> >>> Why are they comparing documents at all? That's more work! They only >>> need to be looking at one document: the one that was in force at the time >>> of the validation. >>> >>>> 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. >>>> >>> They have to make that determination *anyway*, which yes is hard and we >>> should fix that, but providing a BR version in the log line does not make >>> their job any easier. >>> >>> 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/5888dc3f-7ce6-4037-adc7-4c3d67cf684an%40mozilla.org >> >> <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/5888dc3f-7ce6-4037-adc7-4c3d67cf684an%40mozilla.org?utm_medium=email&utm_source=footer> >> . >> > -- 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/80ae0891-d1a7-4823-9f5a-18a1230660d0n%40mozilla.org.
