(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-policy@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/0d72d9be5acca17ada34cf7e380741e27ee84e55 > > > > > https://github.com/BenWilson-Mozilla/pkipolicy/commit/888dc139d196b02707d228583ac20564ddb27b35 > > > > Or here: > > > https://github.com/BenWilson-Mozilla/pkipolicy/blob/2.7.1/rootstore/policy.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
