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 [email protected] <[email protected]> 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 <[email protected]> > *Sent:* Thursday, November 11, 2021 11:47 AM > *To:* Corey Bonnell <[email protected]>; Ben Wilson < > [email protected]> > *Cc:* [email protected] <[email protected]> > *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 > [email protected] 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 <[email protected]> <[email protected]> > *Sent:* Wednesday, November 10, 2021 5:46 PM > *To:* Corey Bonnell <[email protected]> > <[email protected]> > *Cc:* [email protected] <[email protected]> > <[email protected]> > *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 <[email protected]> > 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:* [email protected] <[email protected]> *On > Behalf Of *Ben Wilson > *Sent:* Monday, November 1, 2021 2:58 PM > *To:* [email protected] <[email protected]> > *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 <[email protected]> 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 " > [email protected]" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > 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 > "[email protected]" <[email protected]> group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > 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 " > [email protected]" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > 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 "[email protected]" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAPh8bk8kBCOR_2Af00HXnSYrYj%3D-EfCMvd05J31otUAq8Cj0JQ%40mail.gmail.com.
