Also, I neglected to mention it before, but this issue is also related to Issue #173. While section 7.1 already states that CAs must provide evidence of CA compliance from "creation," the Issue #173 proposal is that section 7.1 be amended to say, "Before being included, CAs MUST provide evidence that their CA certificates fully comply with the current Mozilla Root Store Requirements and Baseline Requirements*, and have continually, from the time of CA private key creation, complied with the then-current Mozilla Root Store Policy and Baseline Requirements*." I don't believe I received any comments on that language. See https://groups.google.com/g/mozilla.dev.security.policy/c/DChXLJrMwag/m/uGpEqiEcBgAJ
On Sat, Mar 6, 2021 at 9:17 PM Ben Wilson <bwil...@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-security-policy@lists.mozilla.org> wrote: > >> On Thursday, February 25, 2021 at 2:30:52 PM UTC-5, bwi...@mozilla.com >> wrote: >> > I haven't seen any response to my question about whether there is still >> a >> > concern over the language "as evidenced by a Qualified Auditor's key >> > destruction report". >> > I did add "This cradle-to-grave audit requirement applies equally to >> > subordinate CAs as it does to root CAs" to address the scenarios that >> were >> > raised. >> > So I am going to assume that this issue is resolved and that we can >> move >> > this proposed change forward. >> > See >> > >> https://github.com/BenWilson-Mozilla/pkipolicy/commit/c8bdb949020634b1f8fa31bc060229c600fe6f9d >> >> Ben, sorry for the late input. >> >> We are onboard with the cradle-to-grave audit as we have experience >> auditing non-functioning CAs before they go into production and after they >> have stopped issuing certificates. However, I think there might be an issue >> in the requirement with the start and stop time of cradle-to-grave. >> >> At the beginning, I think that CAs will generate one or many keys, but >> will not assign them to CAs. The gap period could be days to years. Since >> the requirement says "from the time of CA key pair generation", do we want >> an audit of an unassigned key? Or should the audit start once the key has >> been assigned and the CA certificate has been generated? >> >> At the end, subordinate CA certificate(s) may be revoked or may expire. >> Once the certificate(s) are revoked or expired, is this a reasonable time >> to stop auditing the CA as trust has been removed? Of course if the >> certificates are not revoked or expired, then all copies of the keys should >> be destroyed to stop the audit. However, I think the best practice should >> be that certificates should be revoked/expired at time of key destruction. >> _______________________________________________ >> 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
