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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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