All, The proposed change currently reads,
"Full-surveillance period-of-time audits MUST be conducted and updated audit information provided no less frequently than annually from the time of CA key pair generation until the CA certificate is no longer trusted by Mozilla's root store or until all copies of the CA private key have been completely destroyed, as evidenced by a Qualified Auditor's key destruction report, whichever occurs sooner. This cradle-to-grave audit requirement applies equally to subordinate CAs as it does to root CAs. Successive period-of-time audits MUST be contiguous (no gaps)." But is the argument that I should also add something along these lines--"This cradle-to-grave audit requirement applies equally to ..., *and an audit would be required for all subordinate CAs until their private keys have been completely destroyed as well*."? Is that still the issue here? Or has it already been resolved with the language further above? Thanks, Ben On Sun, Jan 24, 2021 at 12:55 PM Ben Wilson <bwil...@mozilla.com> wrote: > I agree that we should add language that makes it more clear that the key > destruction exception for audit only applies to the CA certificates whose > key has been destroyed. I'm also hoping that a CAO wouldn't destroy a Root > CA key if there were still valid subordinate CAs that the CAO might need to > revoke. > > On Fri, Nov 6, 2020 at 10:49 AM Jakob Bohm via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > >> On 2020-11-05 22:43, Tim Hollebeek wrote: >> > So, I'd like to drill down a bit more into one of the cases you >> discussed. >> > Let's assume the following: >> > >> > 1. The CAO [*] may or may not have requested removal of the CAC, but >> removal >> > has not been completed. The CAC is still trusted by at least one public >> > root program. >> > >> > 2. The CAO has destroyed the CAK for that CAC. >> > >> > The question we've been discussing internally is whether destruction >> alone >> > should be sufficient to get you out of audits, and we're very skeptical >> > that's desirable. >> > >> > The problem is that destruction of the CAK does not prevent issuance by >> > subCAs, so issuance is still possible. There is also the potential >> > possibility of undisclosed subCAs or cross relationships to consider, >> > especially since some of these cases are likely to be shutdown >> scenarios for >> > legacy, poorly managed hierarchies. Removal may be occurring >> *precisely* >> > because there are doubts about the history, provenance, or scope of >> previous >> > operations and audits. >> > >> > We're basically questioning whether there are any scenarios where >> allowing >> > someone to escape audits just because they destroyed the key is likely >> to >> > lead to good outcomes as opposed to bad ones. If there aren't >> reasonable >> > scenarios where it is necessary to be able to remove CACs from audit >> scope >> > through key destruction while they are still trusted by Mozilla, it's >> > probably best to require audits as long as the CACs are in scope for >> > Mozilla. >> > >> > Alternatively, if there really are cases where this needs to be done, it >> > would be wise to craft language that limits this exception to those >> > scenarios. >> > >> >> I believe that destruction of the Root CA Key should only end audit >> requirements for the corresponding Root CA itself, not for any of its >> still trusted SubCAs. >> >> One plausible (but hypothetical) sequence of events is this: >> >> 1. Begin Root ceremony with Auditors present. >> >> 1.1 Create Root CA Key pair >> 1.2 Sign Root CA SelfCert >> 1.3 Create 5 SubCA Key pairs >> 1.4 Sign 5 SubCA pre-certificates >> 1.5 Request CT Log entries for the 5 SubCA pre-certificates >> 1.6 Sign 5 SubCA certificates with embedded CTs >> 1.7 Sign, but do not publish a set of post-dated CRLs for various >> contingencies >> 1.8 Sign, but do not publish a set of post-dated revocation OCSP >> responses for those contingencies >> 1.9 Sign, but do not yet publish, a set of post-dated non-revocation >> OCSP responses confirming that the SubCAs have not been revoked on each >> date during their validity. >> 1.10 Destroy Root CA Key pair. >> >> 2. Initiate audited storage of the unreleased CRL and OCSP signatures. >> >> 3. End Root ceremony, end root CAC audit period. >> >> 4. Release public audit report of this ceremony, this ends the ordinary >> audits required for the Root CA Cert. However audit reports that only >> the correct contingency and continuation OCSP/CRL signatures were >> released from storage remain technically needed. >> >> 5. Maintain revocation servers that publish the prepared CRLs and OCSP >> answers according to their embedded dates. Feed their publication queue >> from audited batch releases from the storage. >> >> 6. Operate the 5 SubCAs under appropriate security and audit schemes >> detailed in CP/CPS document pairs. >> >> 7. Apply for inclusion in the Mozilla root program. >> >> >> In the above hypothetical scenario, there would be no way for the the >> CAO to misissue new SubCAs or otherwise misuse the root CA Key Pair, but >> still the usual risks associated with the 5 SubCA operations. >> >> Also the CAO would have no way to increase the set of top level SubCAs >> or issue revocation statements in any yet-to-be-invented data formats, >> even if doing so would be legitimate or even required by the root >> programs. >> >> Thus the hypothetical scenario could land the CAO in an impossible >> situation, if root program requirements or common CA protocols change, >> and those changes would require even one additional signature by the >> root CA Key Pair. >> >> >> Enjoy >> >> Jakob >> -- >> Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com >> Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 >> This public discussion message is non-binding and may contain errors. >> WiseMo - Remote Service Management for PCs, Phones and Embedded >> _______________________________________________ >> 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
