I am sorry, I meant for this to go to the ballot discussion and not here. Please direct any comments to that in that thread.
Ryan Hurst On Friday, April 3, 2026 at 2:08:34 PM UTC-7 Ryan Hurst wrote: > 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/00f194dd-31c8-498c-9ac2-0f6d0b6cbfaen%40mozilla.org.
