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]" 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%2B1gtaaOoHe8dOGPO8eqB3uXLbt%3DwXxhXMUA0MpO-Y_kBm%3DwXg%40mail.gmail.com.
