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