There is also the classic email problem. I signed email ages ago using X.509 certs chained off of roots that are (probably) now expired (it's been 20 years).
It would be nice to be able to check those email signatures/etc... Just because a certificate is expired doesn't mean it isn't still useful/etc. Not everything is an HTTPS session. On Thu, May 25, 2023 at 4:34 PM 'Andy Warner' via [email protected] <[email protected]> wrote: > What problem do you believe would be solved by requiring destruction of > key material prior to expiration? Sadly, there are a lot of IoT, embedded > devices and older phones that still rely heavily on expired roots and > cannot be updated practically. You'd create a lot of e-waste and upset a > lot of consumers / enterprises if this proposal was adopted. Should the > device ecosystem work this way, no, but it reality, it does. The > ramifications of such a change would need to be well understood and > evaluated against any potential benefit. > On Thursday, May 25, 2023 at 5:11:25 AM UTC-6 Doug Beattie wrote: > >> The below is true except in the case of Code Signing CAs where there are >> requirements to maintain revocation services after the CA has expired, and >> to also be able to add expired certificates to the CRL, but that's an >> entirely different ecosystem than the one we're discussing here.... >> >> Doug >> >> -----Original Message----- >> From: [email protected] <[email protected]> On Behalf Of >> Jeffrey Walton >> Sent: Thursday, May 25, 2023 1:55 AM >> To: Seo Suchan <[email protected]> >> Cc: [email protected] >> Subject: Re: Is there a rule about root keys that already expired? >> >> On Thu, May 25, 2023 at 12:51 AM Seo Suchan <[email protected]> wrote: >> > >> > Most of root store policies are not apply to them as they are no >> > longer publicly trusted as they are removed from trust store, but >> > there are enough unupdated clients that still trust such certificates >> > (mostly androids/ iot, I think) >> > >> > should trust store start to require destroying root private key just >> > before its expireation? however then catastrophic event happens that >> > caused reject the CA does not have incentive to do any more about it >> > though >> >> A CA's liability ends when the certificate expires. Throw the certificate >> away at expiration. >> >> There's no need to check for revocation either. Potential revocation ends >> at expiration. A key that is compromised after expiration will not lead to >> a CRL entry. >> >> Jeff >> >> -- >> 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/CAH8yC8mPiOdfQ%2Bxtdsi669uCra6jAyv3QXfEmX-%3DQDfyqyZNww%40mail.gmail.com. >> >> > -- > 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/ef771e2c-cf04-4c31-996e-061ae563a942n%40mozilla.org > <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/ef771e2c-cf04-4c31-996e-061ae563a942n%40mozilla.org?utm_medium=email&utm_source=footer> > . > -- Kurt Seifried (He/Him) [email protected] -- 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/CABqVa3_-fR2JoSaVACMG2r-ovsN7OdayeKziVw_ryQoXmDdhBQ%40mail.gmail.com.
