The way I understand it is, generally speaking, Root CAs may be kept in a root store for as long as the root key material is not compromised in any way. In practice Root CA certificates are removed at the operator's request when they believe it is no longer needed, or the root store operator believes it should be removed due to the key material being vulnerable to brute forcing, or some other policy reason (e.g. violation or misuse). Of course it is possible for renewed Root CA certificates to replace older ones as long as they are signed with the same key material- allowing everything else chained to it still be valid (I've seen this happen once with the "GlobalSign Root CA" originally published back in 1998.) While keeping expired Root CAs may not useful for web server certificates chaining up to an expired CA certificate, it is useful for codesigning certificates. Timestamped codesigned objects can continue to work after their certificate has expired as the "timestamp" shows that a certificate was valid *at the time it performed the signature*. Have a look here: https://serverfault.com/questions/878919/what-happens-to-code-sign-certificates-when-when-root-ca-expires . Samuel Pinder
On Mon, Jul 15, 2019 at 1:32 AM Vincent Lours via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Monday, 15 July 2019 04:41:12 UTC+10, Ryan Sleevi wrote: > > Thanks for mentioning this here. > > > > Could you explain why you see it as an issue? RFC 5280 defines a trust > > anchor as a subject and a public key. Everything else is optional, and > the > > delivery of a trust anchor as a certificate does not necessarily imply > the > > constraints of that certificate, including expiration, should apply. > > > > Hi Ryan, > > Thanks for your message. > > First of all, I never said that was an issue. I was just reporting some > expired Root CA, as I was thinking that may impact peoples. > > Secondly, I was not aware of the RFC 5280 defining a trust anchor as a > subject and a public key. > However, if you referrer to the same RFC, they defined a Public Key in the > "4.1.2.5. Validity" Section: > > "When the issuer will not be able to maintain status information until > the notAfter date (including when the notAfter date is > 99991231235959Z), the issuer MUST ensure that no valid certification > path exists for the certificate after maintenance of status information > is terminated. > This may be accomplished by expiration or > revocation of all CA certificates containing the public key used to > verify the signature on the certificate and discontinuing use of the > public key used to verify the signature on the certificate as a trust > anchor." > > In the case of the "certdata.txt", this file is including Public CA > certificates. So an expired certificate means that the key cannot be used > anymore. > > I'm still not expressing this message as an issue, but an suggestion to > update/remove those expired Public Keys from your certdata.txt. > > Cheers, > _______________________________________________ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
