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

[Ben Wilson via dev-security-policy]

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  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-security-policy@lists.mozilla.org> wrote:
>
>> 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.
>> ___
>> 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

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

[Ben Wilson via dev-security-policy]

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

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

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

[Bruce via dev-security-policy]

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.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Ben Wilson via dev-security-policy]

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  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-security-policy@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.
>> ___
>> 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

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

[Ben Wilson via dev-security-policy]

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-security-policy@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.
> ___
> 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

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

[Matt Palmer via dev-security-policy]

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

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Bruce via dev-security-policy]

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.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Ben Wilson via dev-security-policy]

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

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

[Ben Wilson via dev-security-policy]

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

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

[Ben Wilson via dev-security-policy]

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

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

[Ben Wilson via dev-security-policy]

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
>

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

[Jakob Bohm via dev-security-policy]

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

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

[Tim Hollebeek via dev-security-policy]

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 
On
> Behalf Of Ryan Sleevi via dev-security-policy
> Sent: Wednesday, November 4, 2020 2:04 PM
> To: Corey Bonnell 
> Cc: Mozilla 
> 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 

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

[Ryan Sleevi via dev-security-policy]

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

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

[Corey Bonnell via dev-security-policy]

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