Thanks, Wayne. I'll work on clarifying these points. On Thu, Nov 11, 2021 at 1:10 PM Wayne Thayer <wtha...@gmail.com> wrote:
> Hi Ben, > > I'm confused by a few points on the wiki page: > * Under 'Required Documentation', a key generation report is required. > This makes sense in the case where a root CA is cross-signing a > pre-existing CA key pair operated by a third party, but how is this > intended to work if a subCA (including the key pair) is to be generated > after the public discussion? > * Bullet 4 of that section, titled 'Audits' presumably would be met in the > case where the subordinate CA operator already has audits by providing > those audit reports, but I don't understand where "a publishable statement > or letter from an auditor" comes in to play or how that is different from > an audit report? > > My confusion may stem from a lack of understanding of the process for > standing up a new subordinate CA operator that doesn't have its own root. > > Thanks, > > Wayne > > On Thu, Nov 11, 2021 at 10:26 AM 'Corey Bonnell' via > dev-security-policy@mozilla.org <dev-security-policy@mozilla.org> wrote: > >> > Is it necessary to start a new discussion every time a new CA >> Certificate is about to be issued for that same type and class, or not ? >> Ben, would it make sense to add a new section to address this issue so >> there is no confusion? >> >> >> >> One major downside of mandating a public discussion for the issuance of a >> subCA certificate of the same type and class is one of agility: the >> requirement for public discussion would be a disincentive for shorter subCA >> certificate validity periods. Additionally, if revocation is required for a >> subCA certificate, the requirement for a public discussion and approval for >> its replacement would likely be an impediment to the timely revocation and >> replacement process. >> >> >> >> Thanks, >> >> Corey >> >> >> >> *From:* Dimitris Zacharopoulos <ji...@it.auth.gr> >> *Sent:* Thursday, November 11, 2021 11:47 AM >> *To:* Corey Bonnell <corey.bonn...@digicert.com>; Ben Wilson < >> bwil...@mozilla.com> >> *Cc:* dev-secur...@mozilla.org <dev-security-policy@mozilla.org> >> *Subject:* Re: Policy 2.8: MRSP Issue #233: Wiki page documenting >> process for reviewing externally operated subordinate CAs >> >> >> >> One more issue to clarify is what happens during the SubCA renewal >> process (and what "renewal" means), or issuance of another subCA to an >> organization that has already been approved for the same certificate type >> (server or email) and class (EV or not for server certificates). >> >> Is it necessary to start a new discussion every time a new CA Certificate >> is about to be issued for that same type and class, or not ? Ben, would it >> make sense to add a new section to address this issue so there is no >> confusion? >> >> Also, where would the information about the unconstrained external SubCAs >> that have passed public discussion and have been approved or denied be >> located? >> >> >> Thanks, >> Dimitris. >> >> On 11/11/2021 3:21 μ.μ., 'Corey Bonnell' via >> dev-security-policy@mozilla.org wrote: >> >> Hi Ben, >> >> I think the expectation can be clarified by amending the paragraph >> starting with “The process outlined herein applies to subCA operators not >> already in the Mozilla root program”. I suggest explicitly mentioning the >> three different types of trust, namely Email, (non-EV) Websites, and EV >> Websites and requiring the process be followed whenever an organization is >> to receive a subCA certificate that grants one or more of those technical >> capabilities that the organization did not have in the Mozilla root >> program. As a concrete proposal: >> >> >> >> “The process outlined herein applies to organizations that do not control >> a Root or subCA certificate trusted by the Mozilla root program. >> Additionally, the process outlined herein applies to organizations that >> control a subCA or Root CA certificate in Mozilla’s root program but the >> new subCA certificate will grant technical capability for the issuance of >> additional types of certificates. Specifically, the process outlined herein >> MUST be followed when an organization does not control a subCA or Root CA >> certificate that grants capability to issue certificates of one or more of >> the following types and the new subCA certificate will grant such >> capability: S/MIME (Email trust bit), (DV/IV/OV) TLS Server Authentication >> (Websites trust bit), and/or EV TLS Server Authentication (Websites trust >> bit with EV-enablement).” >> >> >> >> Thanks, >> >> Corey >> >> >> >> *From:* Ben Wilson <bwil...@mozilla.com> <bwil...@mozilla.com> >> *Sent:* Wednesday, November 10, 2021 5:46 PM >> *To:* Corey Bonnell <corey.bonn...@digicert.com> >> <corey.bonn...@digicert.com> >> *Cc:* dev-secur...@mozilla.org <dev-security-policy@mozilla.org> >> <dev-security-policy@mozilla.org> >> *Subject:* Re: Policy 2.8: MRSP Issue #233: Wiki page documenting >> process for reviewing externally operated subordinate CAs >> >> >> >> Hi Corey, >> >> >> >> I think I'll disagree with your conclusion that there is no need to >> perform a review of Sub CA B for issuance of a new intermediate certificate >> to it with the serverAuth EKU. >> >> >> >> Let's assume that Root CA A already has both the websites bit and the >> email bit enabled by Mozilla. And assume that the review-and-comment >> process for Sub CA B focused only on the enablement of that CA for S/MIME >> certificate issuance. What if there had not been a thorough review of Sub >> CA B's Compliance Self Assessment (Required Documentation >> <https://wiki.mozilla.org/CA/Subordinate_CA_Checklist#Required_Documentation> >> #6) because much of the assessment applies only to server certificate >> issuance (i.e. what if the assessment had been filled with a lot of >> "N/A"s)? Then, the prior public discussion was insufficient.("Prior to >> public discussion, the root CA operator must confirm that it has verified >> all of the following information, which must be provided when the root CA >> operator starts the public discussion.") >> >> >> >> However, all of this might be different if the review of Sub CA B was >> thorough enough to cover server certificate issuance. >> >> >> >> I suppose I can make that more clear on the wiki page. I also welcome any >> suggestions. >> >> >> >> Thanks, >> >> Ben >> >> >> >> >> >> On Tue, Nov 9, 2021 at 3:30 PM Corey Bonnell <corey.bonn...@digicert.com> >> wrote: >> >> Hi Ben, >> >> A scenario came to mind that may deserve further clarity in the text, so >> I wanted to raise it here. Suppose Root CA “A” kicks off the >> information-gathering and review process for Sub CA “B” (as outlined on the >> Wiki page) for the issuance of a subordinate CA certificate containing >> solely id-kp-emailProtection. The discussion ends favorably and Sub CA B is >> marked in CCADB as an “approved” organization. Some time later, Sub CA B >> wishes to obtain a subordinate certificate containing id-kp-serverAuth. >> Since this organization has previously been approved, according to the >> proposed language, there is no need to undergo the review and approval >> process again despite the difference in technical capability and audit >> requirements of the subordinate CAs. >> >> >> >> Is this an accurate read of the proposed language? >> >> >> >> Thanks, >> >> Corey >> >> >> >> *From:* dev-security-policy@mozilla.org <dev-security-policy@mozilla.org> >> *On Behalf Of *Ben Wilson >> *Sent:* Monday, November 1, 2021 2:58 PM >> *To:* dev-secur...@mozilla.org <dev-security-policy@mozilla.org> >> *Subject:* Re: Policy 2.8: MRSP Issue #233: Wiki page documenting >> process for reviewing externally operated subordinate CAs >> >> >> >> I am proposing that we create a link in the MRSP to the process for >> review and approval of third-party externally operated CAs as indicated in >> the following commit: >> >> >> https://github.com/BenWilson-Mozilla/pkipolicy/commit/9efa9e73f6cff7924d1ed856eadd1902f31bd458 >> >> >> >> On Thu, Oct 28, 2021 at 2:56 PM Ben Wilson <bwil...@mozilla.com> wrote: >> >> All, >> >> >> >> This email introduces another issue selected to be addressed in the next >> version of the Mozilla Root Store Policy (MSRP), version 2.8, to be >> published in 2022. (See https://github.com/mozilla/pkipolicy/labels/2.8) >> >> >> >> This is Github Issue #233 >> <https://github.com/mozilla/pkipolicy/issues/233>. >> >> >> >> I have re-published the wiki page for the process of reviewing and >> approving externally operated subordinate CAs. Here is the URL: >> >> >> https://wiki.mozilla.org/CA/Subordinate_CA_Checklist#Process_for_Review_and_Approval_of_Externally_Operated_Subordinate_CAs >> >> >> >> This issue is also related to an m.d.s.p. email that I sent and comments >> received with a subject line: Process for Considering Externally >> Operated Subordinate CAs >> <https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/AA5G1bzOwZQ/m/v4i0_wj9BAAJ> >> . >> >> >> >> Please provide any additional comments you may have regarding the review >> and approval process for externally operated subordinate CAs. >> >> >> >> Thanks, >> >> >> >> Ben Wilson >> >> Mozilla Root Program Manager >> >> >> >> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "dev-security-policy@mozilla.org" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to dev-security-policy+unsubscr...@mozilla.org. >> To view this discussion on the web visit >> https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtaZX%2B_vWSyZe2tMGREjurRRV7y66AVMQyLkPz8LE4BbsUw%40mail.gmail.com >> <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtaZX%2B_vWSyZe2tMGREjurRRV7y66AVMQyLkPz8LE4BbsUw%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> >> -- >> You received this message because you are subscribed to the Google Groups >> "dev-security-policy@mozilla.org" <dev-security-policy@mozilla.org> >> group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to dev-security-policy+unsubscr...@mozilla.org. >> To view this discussion on the web visit >> https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/DM6PR14MB2186D6FBA3B3CC7FD7EAF7C492949%40DM6PR14MB2186.namprd14.prod.outlook.com >> <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/DM6PR14MB2186D6FBA3B3CC7FD7EAF7C492949%40DM6PR14MB2186.namprd14.prod.outlook.com?utm_medium=email&utm_source=footer> >> . >> >> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "dev-security-policy@mozilla.org" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to dev-security-policy+unsubscr...@mozilla.org. >> To view this discussion on the web visit >> https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/DM6PR14MB21865C2697186531420A39FD92949%40DM6PR14MB2186.namprd14.prod.outlook.com >> <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/DM6PR14MB21865C2697186531420A39FD92949%40DM6PR14MB2186.namprd14.prod.outlook.com?utm_medium=email&utm_source=footer> >> . >> > -- You received this message because you are subscribed to the Google Groups "dev-security-policy@mozilla.org" group. To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-policy+unsubscr...@mozilla.org. To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtaYnPcNjKmhcPeVUeCxuqn56dP6MJSPkYYsiqgb3dz6Nbw%40mail.gmail.com.
