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/CAEmnErfmXbFxL5R9kqNKp54GTaUP5aTNo-VNsor9bQ98yGKK_g%40mail.gmail.com.
