All, I moved this section to its own wiki page - https://wiki.mozilla.org/CA/External_Sub_CAs_not_Technically_Constrained. I also added a link to it from the CA Program home page - https://wiki.mozilla.org/CA#Information_for_CAs. Ben
On Fri, Nov 19, 2021 at 4:12 PM Ben Wilson <[email protected]> wrote: > 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%2B1gtaYcQFqHQwtDX6e2LkCn6m2OedSPcur0U_uyfahLYgfTLQ%40mail.gmail.com.
