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 이(가) 쓴 글:
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/d9ea4fbd-e632-35a7-0588-305224ad23e4%40gmail.com.
