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, or even better if the certificates themselves logged the reality, but 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 On Tuesday, February 24, 2026 at 8:44:26 PM UTC-8 Ryan Hurst wrote: > 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/df0463ba-9b24-4e1c-b24c-2196e6d64f70n%40mozilla.org.
