Policy 2.7.1: MRSP Issue #153: Cradle-to-Grave Contiguous Audits

[Ben Wilson]

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

[Corey Bonnell]

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

[Ryan Sleevi]

(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-secur...@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:

> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>

[Tim Hollebeek]

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".

> securit...@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:

[Jakob Bohm]

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

[Ben Wilson]

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-secur...@lists.mozilla.org> wrote:

> On 2020-11-05 22:43, Tim Hollebeek wrote:

[Ben Wilson]

As proposed, changes to section 3.1.3 of the MRSP do not make any
distinction between root CAs and subordinates. Nonetheless, what if we
added this sentence to MRSP section 3.1.3, "This cradle-to-grave audit
requirement applies equally to subordinate CAs as it does to root CAs."?
If that does not resolve the issues raise, please provide recommended edits
to section 3.1.3 of the MRSP that will make it more clear and less
susceptible to misinterpretation.

On Sun, Jan 24, 2021 at 12:55 PM Ben Wilson <bwi...@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-secur...@lists.mozilla.org> wrote:
>
>> On 2020-11-05 22:43, Tim Hollebeek wrote:

[Ben Wilson]

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 <bwi...@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-secur...@lists.mozilla.org> wrote:
>
>> On 2020-11-05 22:43, Tim Hollebeek wrote:

[Ben Wilson]

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 <bwi...@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 <bwi...@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-secur...@lists.mozilla.org> wrote:
>>
>>> On 2020-11-05 22:43, Tim Hollebeek wrote:

[Bruce]

On Thursday, February 25, 2021 at 2:30:52 PM UTC-5, bwi...@mozilla.com wrote:
> 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

Ben, sorry for the late input.

We are onboard with the cradle-to-grave audit as we have experience auditing non-functioning CAs before they go into production and after they have stopped issuing certificates. However, I think there might be an issue in the requirement with the start and stop time of cradle-to-grave.

At the beginning, I think that CAs will generate one or many keys, but will not assign them to CAs. The gap period could be days to years. Since the requirement says "from the time of CA key pair generation", do we want an audit of an unassigned key? Or should the audit start once the key has been assigned and the CA certificate has been generated?

At the end, subordinate CA certificate(s) may be revoked or may expire. Once the certificate(s) are revoked or expired, is this a reasonable time to stop auditing the CA as trust has been removed? Of course if the certificates are not revoked or expired, then all copies of the keys should be destroyed to stop the audit. However, I think the best practice should be that certificates should be revoked/expired at time of key destruction.

[Matt Palmer]

On Fri, Mar 05, 2021 at 08:46:26AM -0800, Bruce via dev-security-policy wrote:
> At the beginning, I think that CAs will generate one or many keys, but
> will not assign them to CAs. The gap period could be days to years.
> Since the requirement says "from the time of CA key pair generation", do
> we want an audit of an unassigned key? Or should the audit start once the
> key has been assigned and the CA certificate has been generated?

I think it's reasonable that keys that are bound to CA certificates have an
unbroken history of audits demonstrating that the key has always been
managed in a way that minimises the chances of disclosure, along with
evidence that the key being bound was initially generated in a secure manner
(good RNG, etc).

- Matt

[Ben Wilson]

Thanks, Bruce, for raising the issue of pre-generated, yet unassigned keys.
The intent was to cover this scenario. We are aware that CAs might
generate 1000s of keys in a partition and then years later assign a few of
them as CA keys, others as OCSP responder keys, etc., and some might never
be used. Presumably each of the keys would have an identifier and the CA
operator would maintain a list of those key identifiers for each partition.
The goal is to have an audited chain of custody for the keys, which could
also be based on the physical and logical protection of the HSM that is
holding them.
Key lifecycle documentation would consist of a documented key generation
ceremony (where such documentation is reviewed by an auditor). Then,
annually an auditor would review storage and access records for the HSM(s)
and the list of keys to see which ones had been used for CAs and which ones
had not. Then, as keys were destroyed (or if not, when the HSM is zeroized
at the end of the HSM's lifecycle), there would be an attestation of key
destruction that would be covered by an audit/auditor's statement.

On Fri, Mar 5, 2021 at 9:46 AM Bruce via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> On Thursday, February 25, 2021 at 2:30:52 PM UTC-5, bwi...@mozilla.com
> wrote:

> > 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
>

> Ben, sorry for the late input.
>
> We are onboard with the cradle-to-grave audit as we have experience
> auditing non-functioning CAs before they go into production and after they
> have stopped issuing certificates. However, I think there might be an issue
> in the requirement with the start and stop time of cradle-to-grave.
>

> At the beginning, I think that CAs will generate one or many keys, but
> will not assign them to CAs. The gap period could be days to years. Since
> the requirement says "from the time of CA key pair generation", do we want
> an audit of an unassigned key? Or should the audit start once the key has
> been assigned and the CA certificate has been generated?
>

> At the end, subordinate CA certificate(s) may be revoked or may expire.
> Once the certificate(s) are revoked or expired, is this a reasonable time
> to stop auditing the CA as trust has been removed? Of course if the
> certificates are not revoked or expired, then all copies of the keys should
> be destroyed to stop the audit. However, I think the best practice should
> be that certificates should be revoked/expired at time of key destruction.

[Ben Wilson]

Also, I neglected to mention it before, but this issue is also related to
Issue #173. While section 7.1 already states that CAs must provide
evidence of CA compliance from "creation," the Issue #173 proposal is that
section 7.1 be amended to say, "Before being included, CAs MUST provide
evidence that their CA certificates fully comply with the current Mozilla
Root Store Requirements and Baseline Requirements*, and have continually,
from the time of CA private key creation, complied with the then-current
Mozilla Root Store Policy and Baseline Requirements*." I don't believe I
received any comments on that language. See
https://groups.google.com/g/mozilla.dev.security.policy/c/DChXLJrMwag/m/uGpEqiEcBgAJ

On Sat, Mar 6, 2021 at 9:17 PM Ben Wilson <bwi...@mozilla.com> wrote:

> Thanks, Bruce, for raising the issue of pre-generated, yet unassigned
> keys. The intent was to cover this scenario. We are aware that CAs might
> generate 1000s of keys in a partition and then years later assign a few of
> them as CA keys, others as OCSP responder keys, etc., and some might never
> be used. Presumably each of the keys would have an identifier and the CA
> operator would maintain a list of those key identifiers for each partition.
> The goal is to have an audited chain of custody for the keys, which could
> also be based on the physical and logical protection of the HSM that is
> holding them.
> Key lifecycle documentation would consist of a documented key generation
> ceremony (where such documentation is reviewed by an auditor). Then,
> annually an auditor would review storage and access records for the HSM(s)
> and the list of keys to see which ones had been used for CAs and which ones
> had not. Then, as keys were destroyed (or if not, when the HSM is zeroized
> at the end of the HSM's lifecycle), there would be an attestation of key
> destruction that would be covered by an audit/auditor's statement.
>
>

> On Fri, Mar 5, 2021 at 9:46 AM Bruce via dev-security-policy <
> dev-secur...@lists.mozilla.org> wrote:
>
>> On Thursday, February 25, 2021 at 2:30:52 PM UTC-5, bwi...@mozilla.com
>> wrote:

>> > 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
>>

>> Ben, sorry for the late input.
>>
>> We are onboard with the cradle-to-grave audit as we have experience
>> auditing non-functioning CAs before they go into production and after they
>> have stopped issuing certificates. However, I think there might be an issue
>> in the requirement with the start and stop time of cradle-to-grave.
>>
>> At the beginning, I think that CAs will generate one or many keys, but
>> will not assign them to CAs. The gap period could be days to years. Since
>> the requirement says "from the time of CA key pair generation", do we want
>> an audit of an unassigned key? Or should the audit start once the key has
>> been assigned and the CA certificate has been generated?
>>
>> At the end, subordinate CA certificate(s) may be revoked or may expire.
>> Once the certificate(s) are revoked or expired, is this a reasonable time
>> to stop auditing the CA as trust has been removed? Of course if the
>> certificates are not revoked or expired, then all copies of the keys should
>> be destroyed to stop the audit. However, I think the best practice should
>> be that certificates should be revoked/expired at time of key destruction.

[Bruce]

On Saturday, March 6, 2021 at 11:17:53 PM UTC-5, bwi...@mozilla.com wrote:
> Thanks, Bruce, for raising the issue of pre-generated, yet unassigned keys.
> The intent was to cover this scenario. We are aware that CAs might
> generate 1000s of keys in a partition and then years later assign a few of
> them as CA keys, others as OCSP responder keys, etc., and some might never
> be used. Presumably each of the keys would have an identifier and the CA
> operator would maintain a list of those key identifiers for each partition.
> The goal is to have an audited chain of custody for the keys, which could
> also be based on the physical and logical protection of the HSM that is
> holding them.
> Key lifecycle documentation would consist of a documented key generation
> ceremony (where such documentation is reviewed by an auditor). Then,
> annually an auditor would review storage and access records for the HSM(s)
> and the list of keys to see which ones had been used for CAs and which ones
> had not. Then, as keys were destroyed (or if not, when the HSM is zeroized
> at the end of the HSM's lifecycle), there would be an attestation of key
> destruction that would be covered by an audit/auditor's statement.
> On Fri, Mar 5, 2021 at 9:46 AM Bruce via dev-security-policy <
> dev-secur...@lists.mozilla.org> wrote:
>

One more question for clarification as I want to make sure we understand how to get our practices updated to meet the Mozilla Policy. The requirement states "until the CA certificate is no longer trusted by Mozilla's root store." Can we confirm that a CA certificate is no longer trusted by the Mozilla root store if 1) it has expired or 2) it has been revoked and the OneCRL has been updated. Of course Mozilla may have other ways to no longer trust a CA certificate.

[Ben Wilson]

Hi Bruce,
I think the answer is yes. A CA certificate is no longer trusted once it
has expired or been revoked (or added to OneCRL for subCAs) or removed
(roots). But I'm double-checking on the case of certificates with validity
periods that extend past the expiration of the root.
Ben

On Thu, Mar 11, 2021 at 7:28 AM Bruce via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> On Saturday, March 6, 2021 at 11:17:53 PM UTC-5, bwi...@mozilla.com wrote:

> One more question for clarification as I want to make sure we understand
> how to get our practices updated to meet the Mozilla Policy. The
> requirement states "until the CA certificate is no longer trusted by
> Mozilla's root store." Can we confirm that a CA certificate is no longer
> trusted by the Mozilla root store if 1) it has expired or 2) it has been
> revoked and the OneCRL has been updated. Of course Mozilla may have other
> ways to no longer trust a CA certificate.

[Ben Wilson]

Bruce,
The answer would be yes because we check the validity of the root CA
certificate and other CA certificates.
Ben

On Thu, Mar 11, 2021 at 10:33 AM Ben Wilson <bwi...@mozilla.com> wrote:

> Hi Bruce,
> I think the answer is yes. A CA certificate is no longer trusted once it
> has expired or been revoked (or added to OneCRL for subCAs) or removed
> (roots). But I'm double-checking on the case of certificates with validity
> periods that extend past the expiration of the root.
> Ben
>

> On Thu, Mar 11, 2021 at 7:28 AM Bruce via dev-security-policy <
> dev-secur...@lists.mozilla.org> wrote:
>
>> On Saturday, March 6, 2021 at 11:17:53 PM UTC-5, bwi...@mozilla.com
>> wrote:

>> One more question for clarification as I want to make sure we understand
>> how to get our practices updated to meet the Mozilla Policy. The
>> requirement states "until the CA certificate is no longer trusted by
>> Mozilla's root store." Can we confirm that a CA certificate is no longer
>> trusted by the Mozilla root store if 1) it has expired or 2) it has been
>> revoked and the OneCRL has been updated. Of course Mozilla may have other
>> ways to no longer trust a CA certificate.