On Saturday, March 6, 2021 at 11:17:53 PM UTC-5, bwi...@mozilla.com wrote: > Thanks, Bruce, for raising the issue of pre-generated, yet unassigned keys. > The intent was to cover this scenario. We are aware that CAs might > generate 1000s of keys in a partition and then years later assign a few of > them as CA keys, others as OCSP responder keys, etc., and some might never > be used. Presumably each of the keys would have an identifier and the CA > operator would maintain a list of those key identifiers for each partition. > The goal is to have an audited chain of custody for the keys, which could > also be based on the physical and logical protection of the HSM that is > holding them. > Key lifecycle documentation would consist of a documented key generation > ceremony (where such documentation is reviewed by an auditor). Then, > annually an auditor would review storage and access records for the HSM(s) > and the list of keys to see which ones had been used for CAs and which ones > had not. Then, as keys were destroyed (or if not, when the HSM is zeroized > at the end of the HSM's lifecycle), there would be an attestation of key > destruction that would be covered by an audit/auditor's statement. > On Fri, Mar 5, 2021 at 9:46 AM Bruce via dev-security-policy < > dev-secur...@lists.mozilla.org> wrote: >
One more question for clarification as I want to make sure we understand how to get our practices updated to meet the Mozilla Policy. The requirement states "until the CA certificate is no longer trusted by Mozilla's root store." Can we confirm that a CA certificate is no longer trusted by the Mozilla root store if 1) it has expired or 2) it has been revoked and the OneCRL has been updated. Of course Mozilla may have other ways to no longer trust a CA certificate. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
