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.
