On Wed, Jul 31, 2024 at 8:45 PM Tyrel <[email protected]> wrote:
> Even with the granted TRO, Digicert should have revoked the certificates > from all other customers within the 24 hour deadline (which did not > happen). > I mean I’m sort of a Delayed Revocation Has Consequences guy, but I think “hmm, a judge says we shouldn’t revoke this one, maybe we should chill on the others too” is a reasonable position to take while counsel sorts the parameters out. I have questions about how BRs 9.6.3(8) manifests in DigiCert’s subscriber agreement/contract chain, but I have high confidence that they will be submitting all of that stuff into evidence here and then 9.16.3 means that it’ll be very clear if it has any effect on their future issuance or revocation. As my therapist says, let’s not “should” all over ourselves here. All of this puts the burden of maintaining flexibility back where it should > be -- on subscribers. Indeed, if anything, this incident suggests that > instead of 24 hr or 5 days, the timeline should be "as soon as the list of > affected certs is assembled, revoke them all." Systems that are not > critical will have outages (which is OK). Systems that are critical will > also have outages in the short term, which is also OK because it > incentivizes hot spares, automation, lifecycle management, and other best > practices to make for an agile ecosystem. > I think this is basically right, unless we discover that the cost of a TRO is lower (in some jurisdictions?) than the cost of rotating certs. That would motivate some contemplation of how the incentives line up, I think. Mike -- 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 on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CADQzZqvjoov_BgXWuuQggwCOitu2r9-vu%3Dkrey_XR%3Dd9frc%2B3A%40mail.gmail.com.
