The private key (which is used to sign things) should be destroyed, since new signatures aren't legitimate after its validity ends, and the creation of new signatures can be used to alter records (which is never a good or even acceptable thing). The now-expired certificate should be kept around, for the reason you describe.
I hope this helps. -Kyle H On Fri, May 26, 2023, 08:28 'Kurt Seifried' via dev-security-policy@mozilla.org <dev-security-policy@mozilla.org> wrote: > What if I want to verify the key used to sign my key used to sign the > email? If you don’t need toot keys to validate things then why are we all > here? It’s turtles all the way down. > > > -Kurt > > > > > > On May 26, 2023, at 2:01 AM, dr. Szőke Sándor <szoke.san...@microsec.hu> > wrote: > > > > You do not need to have the root or any subordinate CA key after the > expiration of the CA certificate to be able to validate a signature. > > > > The CA should issue a closing CRL before the end of its validity, and > after expiry this closing CRL should be published beyond its validity. > > > > The expired CA certificate can not be used to sign any content, so we do > not need the private key. Due to security reasons it is the best to destroy > the unusable private keys. > > > > > > Sándor > > > > > > *From:* 'Kurt Seifried' via dev-security-policy@mozilla.org < > dev-security-policy@mozilla.org> > *Sent:* Friday, May 26, 2023 2:54 AM > *To:* Andy Warner <awar...@google.com> > *Cc:* dev-security-policy@mozilla.org; Doug Beattie < > doug.beat...@globalsign.com>; nolo...@gmail.com <noloa...@gmail.com>; Seo > Suchan <tjtn...@gmail.com> > *Subject:* Re: Is there a rule about root keys that already expired? > > > > 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 > dev-security-policy@mozilla.org <dev-security-policy@mozilla.org> 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: dev-secur...@mozilla.org <dev-secur...@mozilla.org> On Behalf Of > Jeffrey Walton > Sent: Thursday, May 25, 2023 1:55 AM > To: Seo Suchan <tjt...@gmail.com> > Cc: dev-secur...@mozilla.org > Subject: Re: Is there a rule about root keys that already expired? > > On Thu, May 25, 2023 at 12:51 AM Seo Suchan <tjt...@gmail.com> 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 " > dev-secur...@mozilla.org" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to dev-security-po...@mozilla.org. > 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 > <https://www.google.com/url?q=https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAH8yC8mPiOdfQ%252Bxtdsi669uCra6jAyv3QXfEmX-%253DQDfyqyZNww%2540mail.gmail.com&source=gmail-imap&ust=1685692920000000&usg=AOvVaw1MEW9pqhzQ92-YC6MVYbde>. > > > -- > You received this message because you are subscribed to the Google Groups " > dev-security-policy@mozilla.org" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to dev-security-policy+unsubscr...@mozilla.org. > 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://www.google.com/url?q=https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/ef771e2c-cf04-4c31-996e-061ae563a942n%2540mozilla.org?utm_medium%3Demail%26utm_source%3Dfooter&source=gmail-imap&ust=1685692920000000&usg=AOvVaw2gP8oE77uHGeuDkCc9CY0J> > . > > > > > -- > > Kurt Seifried (He/Him) > k...@seifried.org > > -- > You received this message because you are subscribed to the Google Groups " > dev-security-policy@mozilla.org" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to dev-security-policy+unsubscr...@mozilla.org. > 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 > <https://www.google.com/url?q=https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CABqVa3_-fR2JoSaVACMG2r-ovsN7OdayeKziVw_ryQoXmDdhBQ%2540mail.gmail.com?utm_medium%3Demail%26utm_source%3Dfooter&source=gmail-imap&ust=1685692920000000&usg=AOvVaw1waB33K4TxBhW4rgcp05Ja> > . > > -- > You received this message because you are subscribed to the Google Groups " > dev-security-policy@mozilla.org" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to dev-security-policy+unsubscr...@mozilla.org. > To view this discussion on the web visit > https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/1E404211-D25B-43B0-AA81-161867A89E4A%40seifried.org > <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/1E404211-D25B-43B0-AA81-161867A89E4A%40seifried.org?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "dev-security-policy@mozilla.org" group. To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-policy+unsubscr...@mozilla.org. To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CADgtLZ5CVfseLQ3uFcbYLjex60iLgvRbFURwNafyQ%3DtBm0CVXQ%40mail.gmail.com.
