Policy 2.8: MRSP Issue #233: Wiki page documenting process for reviewing externally operated subordinate CAs

[Ben Wilson]

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. 

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.

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

[Ben Wilson]

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

[Corey Bonnell]

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

--
You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@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.

[Ben Wilson]

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 #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

[Corey Bonnell]

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

[Dimitris Zacharopoulos]

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.

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.

[Corey Bonnell]

> 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

[Wayne Thayer]

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

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.

[Ben Wilson]

On Thu, Nov 11, 2021 at 9:47 AM Dimitris Zacharopoulos <ji...@it.auth.gr> wrote:

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.

There is a field in the CCADB for SubCAs that says:

	"Unconstrained SubCA Discussion"

We would likely put information there and include a link to the mdsp discussion and/or bugzilla bug.

Ben

[Ben Wilson]

As a second paragraph, I'm considering inserting:

The process outlined herein applies to organizations that either: do not already operate a root CA or subCA that is trusted by the Mozilla root program, or already operate within the root program, but seek a new subCA certificate that will grant them technical capability for the issuance of certificates that they previously did not have. Specifically, this process 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).

And as a fifth paragraph, I'm considering adding:

And, if a new or modified CA certificate is to be issued to the same operator having already undergone the full process for the type of end entity certificates being issued, then there is no need to repeat this process. 

For example, if the prior process only involved a review for issuance of email certificates, and the CA operator then wants a CA certificate with the serverAuth EKU in order to issue server certificates, then that part of the review process not fully performed must be repeated because of the different requirements and performance expectations. And vice versa, if the CA operator were first approved to issue server certificates and then wanted a CA certificate with the emailProtection EKU to issue email certificates, then any relevant part of the review process that was missed would need to be performed.

[Ben Wilson]

Thanks, Wayne.  I'll work on clarifying these points.

[Ben Wilson]

I have edited the wiki page:

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

[Ben Wilson]

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