Thanks, Ryan I'll work on incorporating your suggestions into the draft we're working on. Ben
On Wed, Mar 10, 2021 at 9:10 AM Ryan Sleevi <r...@sleevi.com> wrote: > > > On Mon, Mar 8, 2021 at 7:08 PM Ben Wilson via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > >> #139 resolved - Audits are required even if no longer issuing, until CA >> certificate is revoked, expired, or removed. >> >> See >> >> https://github.com/BenWilson-Mozilla/pkipolicy/commit/888dc139d196b02707d228583ac20564ddb27b35 >> > > I'm assuming you're OK with this, but just wanting to make sure it's > explicit: > > In the scenario where the CA destroys the private key, they may still have > outstanding certificates that work in Mozilla products. If Mozilla is > relying on infrastructure provided by that CA (e.g. OCSP, CRL), the CA no > longer has an obligation to audit that infrastructure. > > I suspect that the idea is that if/when a CA destroys the private key, > that the expectation is Mozilla will promptly remove/revoke the root, but > just wanted to call out that there is a gap between the operational life > cycle of a CA (e.g. providing revocation services) and the private key > lifecycle. > > If this isn't intended, then removing the "or until all copies" should > resolve this, but of course, open up new discussion. > > >> #221 resolved - Wrong hyperlink for “material change” in MRSP section 8 >> >> Replace hyperlink with “there is a change in the CA's operations that >> could >> significantly affect a CA's ability to comply with the requirements of >> this >> Policy.” >> >> >> https://github.com/BenWilson-Mozilla/pkipolicy/commit/fbe04aa64f931940af967ed90ab98aa95789f057 > > > Since "significantly" is highly subjective, and can lead the CA to not > disclosing, what would be the impact of just dropping the word? That is, > "that could affect a CA's ability to comply". There's still an element of > subjectivity here, for sure, but it encourages CAs to over-disclose, rather > than under-disclose, as the current language does. > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
