Process for Considering Externally Operated Subordinate CAs

[Ben Wilson]

Here is a draft process for your comments and discussion.

DRAFT: Process for Considering Externally Operated Subordinate CAs

Summary

The operator of a Mozilla-trusted root CA is at all times completely and ultimately accountable for every certificate signed under the root CA, whether directly or through subordinate CAs or cross-certified CAs. It is responsible to ensure that the subCA fully and continually complies with requirements.

When a root CA intends to sign an externally operated subordinate CA (subCA) certificate, it is responsible for collecting information and performing due diligence that meets or exceeds that performed by Mozilla on root inclusion requests, and for initiating the public discussion on the Mozilla dev-security-policy mailing list. Following public discussion, the Mozilla CA Program Manager will determine whether or not the subordinate CA will be accepted, and update the corresponding CCADB record to indicate the result.

The process outlined herein applies to subCA operators not already in the Mozilla root program. A different procedure would be followed, for instance, when two CA operators already in the Mozilla root program are creating a cross certificate for interoperability or ubiquity. 

Applicable Policy Provisions

Section 8 of the Mozilla Root Store Policy (MRSP) requires that root CA operators notify Mozilla when a new third party is going to operate a trusted CA outside of the confines of the CA operator’s existing operations. 

According to Section 8 of the Mozilla Root Store Policy,

CAs SHOULD NOT assume that trust is transferable. All CAs whose certificates are included in Mozilla's root program MUST notify Mozilla if:   . . .  an organization other than the CA obtains control of an unconstrained intermediate certificate (as defined in section 5.3.2 of this policy) that directly or transitively chains to the CA's included certificate(s) . . . .  CAs should err on the side of notification if there is any doubt. Mozilla will normally keep commercially sensitive information confidential. Throughout any change, CA operations MUST continue to meet the requirements of this policy.   . . .  CAs are encouraged to notify in advance in order to avoid unfortunate surprises.

Mozilla Root Store Policy section 8.1 states:

If the receiving or acquiring company is new to the Mozilla root program, it must demonstrate compliance with the entirety of this policy and there MUST be a public discussion regarding their admittance to the root program, which Mozilla must resolve with a positive conclusion in order for the affected certificate(s) to remain in the root program. If the entire CA operation is not included in the scope of the transaction, issuance is not permitted until the discussion has been resolved with a positive conclusion.

Process Overview

Information gathering, due diligence, and public discussion should all happen before the signing of the subCA certificate. Prior to signing the subCA, the root CA operator should collect and verify the required documentation, as set forth in the numbered list below. 

The public discussion phase should also occur prior to the signing of the subCA. However, current policy permits public discussion to occur following signing. 

In either case, Mozilla’s prior approval is required because discussion must be “resolved with a positive conclusion” before issuance of end entity certificates.

In any event, public disclosure of the subCA in the CCADB must occur within one week as required by MRSP § 5.3.2. Part of the disclosure involves indicating whether the subCA is covered by the same audits as the parent CA or whether it has a separate audit. 

Required Documentation

Before subCA creation or at the latest one week following subCA creation, a bug should be created in Bugzilla under the NSS Product with a component of “CA Certificate Root Program”. 

The root CA operator must submit an auditor’s key generation report for the key pair that is signed by the root CA. It is also the root CA operator’s obligation to provide audit statements for the subCA. The key generation report and relevant audit statement(s) should be uploaded to the bug in Bugzilla and referenced in the subCA’s record in the CCADB. 

SubCA audits should follow the same audit rules as for root CAs. If the subCA is new, it need only supply a type-1 (point-in-time) audit statement to Mozilla prior to approval. The new subCA certificate must appear in subsequent type-2 (period-of-time) audit statements, but is not required to appear on the statements submitted to Mozilla for approval, so long as the root CA asserts that the subCA will be operated within the scope of the supplied audit statements.  For more information, see Mozilla’s Policy about Third-Party Subordinate CAs.

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 in Mozilla’s dev-security-policy mailing list.

1. External Third Party’s Full Legal Name  

2. External Third Party’s Website URL

3. Expected CA hierarchy under the subCA

4. Audits - If the root CA audits do not include the SHA256 hash for this subCA, then provide a publishable statement or letter from an auditor that meets the requirements of Mozilla's Root Store Policy.

5. Links to the subCA’s current CP/CPS 

• The CA must review the subCA’s CP/CPS for required and prohibited practices. 

After a minimum of 3 weeks have passed, a Mozilla representative will announce a one-week “last call” for objections. Mozilla may determine to extend public discussion, or approve or reject the subCA.  If the subCA is approved, Mozilla will indicate in the appropriate fields of the CCADB that the public discussion process has taken place and that it has been approved as an externally operated CA. Issuance of end entity certificates from the subCA may then commence. If the subCA is rejected, then any existing subCA certificate will be added to OneCRL.

[Ryan Sleevi]

On Thu, Jun 17, 2021 at 11:29 PM Ben Wilson <bwi...@mozilla.com> wrote:

Process Overview

Information gathering, due diligence, and public discussion should all happen before the signing of the subCA certificate. Prior to signing the subCA, the root CA operator should collect and verify the required documentation, as set forth in the numbered list below. 

So, upfront: I think this language is correct, because it avoids ambiguities of expectations. I don't think it should be changed.

However, I did want to highlight a process that some CAs have used in the past, namely: the existing Root CA performs the Root Key Generation Ceremony within their infrastructure, and performs the signing. They then hold on to the private key, and operate the infrastructure, unless/until the new external CA passes the process.

We've seen CAs use that process, but then get confused on expectations, which is why I think the current language (which forbids that) is good. For example, we saw QuoVadis transfer key material to DarkMatter prior to the decision on DarkMatter. We also saw cross-signs that happened in which the external sub-CA performed the RKGC themselves, but the existing CA didn't "release" the certificate to the external CA - even though they CT logged it, which effectively releases it.

I mention this both in the event it comes up in the discussion, and to ask whether it makes sense to make the language/stronger/explicit here. For example, "The Root CA operator MUST NOT sign any certificates for the Sub CA until ... ", to really put in big letters that "The old way is not a good way".

 

The public discussion phase should also occur prior to the signing of the subCA. However, current policy permits public discussion to occur following signing. 

I don't believe this statement is correct, and that was intentional. As you cited, the existing language states:

"If the entire CA operation is not included in the scope of the transaction, issuance is not permitted until the discussion has been resolved with a positive conclusion."

This was explicitly to prevent the scenario I listed above, and require disclosure and approval.

 

In either case, Mozilla’s prior approval is required because discussion must be “resolved with a positive conclusion” before issuance of end entity certificates.

Could you clarify where you see the language restricting only to "end-entity certificates"? We saw CAs respond to similar - i.e. "Oh, we haven't issued any certs yet" - but that's a statement that cannot be verified: it's not covered by the audits, and we wouldn't trust the audits even if it was. The goal was to prevent the capability, not the action.

 

Required Documentation

Before subCA creation or at the latest one week following subCA creation, a bug should be created in Bugzilla under the NSS Product with a component of “CA Certificate Root Program”. 

Ditto re: before vs after, and "discussion completes before" being the goal.

SubCA audits should follow the same audit rules as for root CAs. If the subCA is new, it need only supply a type-1 (point-in-time) audit statement to Mozilla prior to approval. The new subCA certificate must appear in subsequent type-2 (period-of-time) audit statements, but is not required to appear on the statements submitted to Mozilla for approval, so long as the root CA asserts that the subCA will be operated within the scope of the supplied audit statements.  For more information, see Mozilla’s Policy about Third-Party Subordinate CAs.

This seems to switch to the AICPA terms for these, which ETSI does not use. Historically, Mozilla used the language point-in-time and period-of-time (with both their explanations and those in the BRs). Basically, I'd suggest saying "only supply a point-in-time audit statement" or, if you wanted to keep the parenthesis, "only supply a point-in-time (Type 1) audit statement"

 

After a minimum of 3 weeks have passed, a Mozilla representative will announce a one-week “last call” for objections. Mozilla may determine to extend public discussion, or approve or reject the subCA.  If the subCA is approved, Mozilla will indicate in the appropriate fields of the CCADB that the public discussion process has taken place and that it has been approved as an externally operated CA. Issuance of end entity certificates from the subCA may then commence. If the subCA is rejected, then any existing subCA certificate will be added to OneCRL.

I'd suggest making sure that issuance is not performed until an explicit statement from the Module Owner. The reason being that a CA may conclude that they just ran down the clock, and that's a positive disposition, but that wasn't the intent of the language when originally drafted, AIUI.

re: "any existing subCA", I suggest that could be dropped. 

[Matt Palmer]

On Thu, Jun 17, 2021 at 09:29:00PM -0600, Ben Wilson wrote:
> DRAFT: Process for Considering Externally Operated Subordinate CAs

Given the extensive issues observed in the past regarding CA supervision of
their externally-operated subordinates, has Mozilla considered just not
allowing unconstrained externally-operated subordinates? It feels like the
desire is for these external subCAs to be held to the same standards as
trust anchors (as they should be, as the set of risks is the same), so why
not just require all entities who wish to be able to operate an
unconstrained CA to apply directly to Mozilla, and be managed directly by
Mozilla? What's the benefit (to Mozilla, or the subscriber community they
represent) of having a CA in the middle?

- Matt

[Matthew Hardeman]

I echo this question of why not just require them to become direct root program participants?

With the exception of scheduling / queueing for consideration, it appears that an externally operated subCA must in all material respects otherwise qualify with the same burdens as a root program participant.

Economic theory therefore suggests that as the subCA is fully burdened with the costs and principle burdens of becoming a root program member, the commercially probable cause for becoming an externally operated subCA is likely to short-cut time to achieve in-browser trust as a mechanism for reducing time to market.

Perhaps at least restrict externally operated subCAs to applicants who intend independent membership in the root program and have stood up their infrastructure and made full application?  And if the root program inclusion fails, tie that to revoking the subCA as well.

The issue I'm struggling with is "What's the cause for the externally managed unconstrained subCA that justifies substantially all the risk of a new root program participant unless that's where this is imminently headed anyway?"

--
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/20210619000921.GB5902%40hezmatt.org.