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
On Fri, Feb 12, 2021 at 11:16 AM Ben Wilson <bwil...@mozilla.com> wrote: > 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
