I have edited the wiki page: https://wiki.mozilla.org/CA/Subordinate_CA_Checklist#Process_for_Review_and_Approval_of_Externally_Operated_Subordinate_CAs <https://wiki.mozilla.org/CA/Subordinate_CA_Checklist#Process_for_Review_and_Approval_of_Externally_Operated_Subordinate_CAs> I added a note indicating it is a draft, as of 19-Nov-2021. This is an iterative process and there is some duplication of material that is in other parts of the wiki page ( https://wiki.mozilla.org/CA/Subordinate_CA_Checklist#CA_Policies_about_Third-Party_Subordinate_CAs and https://wiki.mozilla.org/CA/Subordinate_CA_Checklist#Third-Party_Subordinate_CAs_that_are_not_Technically_Constrained), so I will continue making changes based on comments received. Thanks, Ben
On Mon, Nov 15, 2021 at 3:21 PM Ben Wilson <[email protected]> wrote: > Thanks, Wayne. I'll work on clarifying these points. > > On Thu, Nov 11, 2021 at 1:10 PM Wayne Thayer <[email protected]> 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 >> [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/CA%2B1gtaZYeH7uwP1asjPDC%2Bkuyru-70yM9d%2BCWtuPo0WV5Y-cHA%40mail.gmail.com.
