On Sun, Jul 14, 2019 at 8:32 PM 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. Hi Vincent, I think you may have misunderstood the section you quoted. This applies to certificates issued by CAs, but does not apply to trust anchors. Trust anchors may be expressed as certificates, but it’s inportant to think of them as trust anchors first, certificates second. For example, the section you cited is about revocation information, but it doesn’t make sense for a root key to provide revocation information about itself, if you think about it. An attacker that compromised the key could just sign a message saying the key is good, defeating the revocation! This is most obvious when you read Section 6.1, and in particular, 6.1.1. RFC 6024 gets into this at more length, trying to explain some of the concepts. This is the same reason that, for example, a root certificate being “signed” with MD5 or SHA-1 doesn’t matter - the signature algorithm, just like the expiration, can be ignored, and the only thing extracted from the root ‘certificate’ is the subject and public key. I highlight this because it shouldn’t impact any Mozilla-using applications, and if any third-party applications are using the Mozilla store, whether or not it impacts them is based on how they have decided to manage their validation libraries independent of Mozilla. I don’t want to suggest it’s not useful to highlight, just highlight that it should not impact anyone, which seemed to be your concern. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
