Is there a rule about root keys that already expired?

[Seo Suchan]

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

[Jeffrey Walton]

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

[Doug Beattie]

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

--
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.

[Andy Warner]

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.

[Kurt Seifried]

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.

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.

--

Kurt Seifried (He/Him)
ku...@seifried.org

[Seo Suchan]

I think it expired roots must manged as if it's still trusted by things (as they are for old device) or confirmed deleted safely: we surely wouldn't want to find out someone selling ICA signed by such keys in darkweb

2023-05-26 오전 7:34에 Andy Warner 이(가) 쓴 글:

[Kurt Seifried]

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....@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-secur...@mozilla.org <dev-secur...@mozilla.org>
Sent: Friday, May 26, 2023 2:54 AM
To: Andy Warner <awa...@google.com>
Cc: dev-secur...@mozilla.org; Doug Beattie <doug.b...@globalsign.com>; nolo...@gmail.com <nolo...@gmail.com>; Seo Suchan <tjt...@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-secur...@mozilla.org <dev-secur...@mozilla.org> wrote:

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.

 

--

Kurt Seifried (He/Him)
ku...@seifried.org

--

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/CABqVa3_-fR2JoSaVACMG2r-ovsN7OdayeKziVw_ryQoXmDdhBQ%40mail.gmail.com.

[Phillip Hallam-Baker]

The WebPKI was built using the available technology of the day and the folk at Surety were incompetent and unreasonable when it came to licensing of the 1990 Haber-Stornetta patent now known as 'blockchain'. We tried to license the patent and even buy it out. The response was always 'you build something and we will tell you how much of the revenue we want'.

If you want to fix any signature in time, you need to sign it and enroll the signature and OCSP token in an authoritative notary chain. The certificate authenticates the key, the chain prevents post-compromise.

If you want to make the notary chain authoritative without using 1% of global electricity, you simply cross notarize the chain with a sufficiently large number of other quasi authoritative chains. This does have the downside of not being able to mint Ponzi coins that can be used to trade drugs, buy CSAM and perpetrate billion dollar FTX frauds if that matters to you.

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.

[Kyle Hamilton]

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

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.