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.
-Tim
[*] I'm going to use the terms CAx, where x = { Organization, Certificate,
Key }, to avoid the ambiguities in the term "CA".
> -----Original Message-----
> From: dev-security-policy <dev-security-policy-boun...@lists.mozilla.org>
On
> Behalf Of Ryan Sleevi via dev-security-policy
> Sent: Wednesday, November 4, 2020 2:04 PM
> To: Corey Bonnell <corey.bonn...@digicert.com>
> Cc: Mozilla <mozilla-dev-security-pol...@lists.mozilla.org>
> Subject: Re: Policy 2.7.1: MRSP Issue #153: Cradle-to-Grave Contiguous
Audits
>
> (Aside: Congrats on the new e-mail address)
>
> The question here is what does "the grave" mean. A common response from
> CAs is "Oh, we stopped issuing TLS certificates from that X years ago,
that's
> why we don't have audits this year", even though a given root (**or**
> subordinate) is still included/transitively trusted.
>
> The goal is to capture that the obligation of a CA exists until they are
fully
> removed, or until they destroy the key.
>
> This also addresses another concern that we saw with the SHA-1
deprecation,
> in which CA's would give notice on a Monday "Please remove our root
> certificate", and then expect that, by Tuesday, they could ignore Mozilla
policy
> requirements and the BRs. That doesn't work, because unless/until the CA
is
> fully removed, Mozilla users, and the broader ecosystem, are at risk. So
this is
> intended to prevent that scenario, by highlighting that merely asking for
> removal isn't sufficient, the removal needs to be completed. And, if that
takes
> too long, the CA has an option to destroy the key (e.g. if they're going
out of
> business).
>
> For the situation you describe, of transference of key material
> control/ownership, that responsibility still continues, plus the added
> intersection of the Section 8 requirements regarding such transfer. The
new
> organization is responsible for providing those continuing audits, or, if
they
> don't like that obligation, the destruction of key material. There's still
> "devious" things that can happen; e.g. old-CA notifies Mozilla on Monday,
> Mozilla approves on Tuesday, new CA requests removal on Wednesday, new
> CA begins shenanigans on Thursday, it's reasonable to ask whether or not
old-
> CA knew that new-CA was going to get up to mischief and what the
> implications are. But that's stuff that would nominally get sorted out on
> Tuesday.
>
> Note that some of this discussion comes from 2 years ago in the CA/B Forum
in
> Shanghai, at https://cabforum.org/2018/10/18/minutes-for-ca-browser-
> forum-f2f-meeting-45-shanghai-17-18-october-2018/#28-Audit-requirements-
> over-the-lifecycle-of-a-root
>
> On Wed, Nov 4, 2020 at 10:14 AM Corey Bonnell via dev-security-policy <
dev-
> security-pol...@lists.mozilla.org> wrote:
>
> > I reviewed the associated GitHub commentary on the following change:
> >
> > "Full-surveillance period-of-time audits MUST be conducted and updated
> > audit information provided no less frequently than **annually** until
> > the CA certificate is no longer trusted by Mozilla's root store.
> > Successive audits 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."
> >
> > and I'm having difficulty understanding why there is a new stipulation
> > to allow for key destruction reports to release a CA from the
> > obligation of annual audits for its CA certificates. Is the intent to
> > specify that if the key material and operations for a given CA is
> > transferred to another organization, the obligation to have annual
> > audits for the original organization no longer stands, or is there
> > some other reason for the addition of this language?
> >
> > Thanks,
> > Corey
> >
> > On Thursday, October 15, 2020 at 5:00:49 PM UTC-4, Ben Wilson wrote:
> > > This issue #153, listed here:
> > > https://github.com/mozilla/pkipolicy/issues/153, is proposed for
> > resolution
> > > with version 2.7.1 of the Mozilla Root Store Policy. It is related
> > > to
> > Issue
> > > 139 <https://github.com/mozilla/pkipolicy/issues/139> (audits
> > > required
> > even
> > > if not issuing).
> > >
> > > The first paragraph of section 3.1.3 of the MRSP would read:
> > >
> > > 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. Successive period-of-time audits
> > > MUST
> > be
> > > contiguous (no gaps).
> > > Item 5 in the fifth paragraph of section 7.1 of the MRSP (new root
> > > inclusions) would read:
> > >
> > > 5. an auditor-witnessed root key generation ceremony report and
> > contiguous
> > > period-of-time audit reports performed thereafter no less frequently
> > than
> > > annually;
> > >
> > > The proposed language can be examined further in the following
commits:
> > >
> > >
> > https://github.com/BenWilson-
> Mozilla/pkipolicy/commit/0d72d9be5acca17a
> > da34cf7e380741e27ee84e55
> > >
> > >
> > https://github.com/BenWilson-
> Mozilla/pkipolicy/commit/888dc139d196b027
> > 07d228583ac20564ddb27b35
> > >
> > > Or here:
> > >
> > https://github.com/BenWilson-Mozilla/pkipolicy/blob/2.7.1/rootstore/po
> > licy.md
> > >
> > > Thanks in advance for your comments,
> > >
> > > Ben
> > _______________________________________________
> > 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
