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/CALVZKwZnrjN-Dt-7-%2BQGTpe1RCjgE3_dsHk1SQdhYaNWwCS_wA%40mail.gmail.com.
