DRAFT of New Policy and Process for Externally-operated Subordinate CAs

[Ben Wilson]

All,

The topic of externally-operated subordinate CAs is complex and needs to be further explained, and the process for approving such subordinate CAs needs to be described in more detail. Therefore, we propose adding a new section 8.4 to MRSP (v.2.8) and re-writing https://wiki.mozilla.org/CA/External_Sub_CAs_not_Technically_Constrained.

The proposed text to replace the current contents of https://wiki.mozilla.org/CA/External_Sub_CAs_not_Technically_Constrained is here:

https://docs.google.com/document/d/1duMqTzx32bfgzQndAy2MfHrx498Y3gxuS6zz6nASL48/edit?usp=sharing 

The proposed text for the new section 8.4 is here:

https://docs.google.com/document/d/1MY_0t-gOhhvP_D0YbhOHf0HstLds2bXFSDJXaOuP8U0/edit?usp=sharing

Thanks,

Ben and Kathleen

[Ryan Sleevi]

On a meta point, there's a lot to review, and the amount of policy changes accreted over the past 6+ months for 2.8 is going to require a whole review to make sure all the things are correct, especially as we see subtle-but-significant changes.

It's unclear whether comments are meant to go to the doc, or the list, or to GitHub, and so that equally makes it difficult to track any relevant context. For archival/visibility, I'm reflecting here to the list

Policy 8.4 draft

• This draft introduces the term "internally-operated CA". I feel like this is a dangerous phrase to introduce given all the issues we've seen in the past of CAs on "internal purposes" CAs and intent vs capability
• The subordinate CA is directly operated by the Issuing CA organization, operated under the exact same policies and practices of the Issuing CA and within the same scope of audit reporting, and no new organizations will be involved in the management or operation of this CA.
• Explanation: The situation I'm trying to carefully word around is where Organization 1 has a CA, and wants to issue a sub-CA. The BRs forbid delegating 3.2.2.4 to a third-party, but CAs may interpret this (arguably, somewhat suspiciously) as "Organization 2 can perform domain validation, provided that they are within the scope of Organization 1's audit". This sort of "audit whitelabeling" is something that has happened with one CA in the past (obvious by looking at which facilities were audited, even though 1 and 2 don't necessarily disclose their relationships or participation), and so it's trying to ensure that Organization 1 needs to be the sole party involved.
• The exception for "Technically Constrained Sub-CAs" is keeping with existing precedent, although in practice, that seems to have been a net-negative for security. I'm not going to argue this policy should change in 2.8, but I note that programs such as Apple seem to no longer allow TCSCs to be exempt from audits or the same supervision as roots, and that seems a net-positive for user security. It is worth thinking for future policy updates whether there should be any TCSC carveouts. TCSCs can still be issued, but would function more similar to managed CAs.
• The "subordinate CA operator" has undergone review - however, that review is done for a particular set of policies and practices. That is, if I get reviewed for (policies and practices Foo), and approved into the MRP, but then I go get a sub-CA for (policies and practices Bar), there's no such review for Bar. 
• The subordinate CA operator has previously undergone Process for ... and the new Subordinate CA certificate will be operated under the exact same policies and practices as the previous review, and under the same scope of audit reporting as the prior Subordinate CA certificate. Newer versions of policies and practices MAY be used, provided that both the existing and new CA certificates both use the exact same versions at all times.
• Ditto the remark about Root

I realize this seems a level of pedantry, but it's trying to clarify that trust is both an organizational concept and a policies and practices concept. Many CA Organizations in the Mozilla Root Program operate multiple hierarchies for different PKI consumers, which is totally fine and arguably fantastic (policy separation is good!). However, trust doesn't transitively extend to the organization under any policy, but rather, the policies and practices that were previously reviewed (or their newer versions, provided the existing CAs are using those same versions)

However, as currently structured, 8.4 puts an obligation on CA, without necessarily a delivery of results or of quantifying expectations. Any interpretation issues can then lead the CA to argue "they did what they thought was required", no matter how incorrect, and historically, Mozilla has seemed unwilling to challenge any CA on the reasonableness of their misunderstandings. The historic mitigation of such risks has been to introduce an explicit confirmation step, to be performed by Mozilla, that the necessary requirements have been met, which seeks to avoid the situation of "We thought our interpretation was OK". The draft wiki page includes the "require approval by Mozilla" clause, but perhaps it makes sense to explicitly incorporate that requirement into 8.4, so that there's no ambiguity of the explicit need for approval?

As worded, it still seems like it's delegating the operation of the Root Program out to third-parties, although it is substantially clearer (in the wiki page) that Mozilla is responsible for performing an evaluation, and this is primarily a data aggregation step.

Process Draft

The current process is improved, in some regards, but notably still permits the Root CA to manage and separate out queues. This seems to a net-negative of the community. Is there a reason the Root CA needs to be the one to start discussion? It seems equally that the process could be:

• Root CA gathers information
• Root CA submits to Mozilla
• Mozilla adds to front of queue
• Mozilla begins discussion as it seems appropriate (e.g. to prevent too many CAs from being in the queue at the same time, or coalesce duplicates, or ensure that the necessary steps by the Root CA have been performed)
• Approval granted

Am I missing some benefit to having the Root CA start the discussion? 

The draft mentions current policy, but doesn't this change with Policy 8.4? e.g. discussion-after-signing seems fundamentally insecure/problematic.

I think it's important to view this policy through the lens of MCS Holdings and CNNIC. CNNIC issued the subordinate CA to MCS that was only valid for 2 weeks, and within those two weeks, users had their TLS connections intercepted, as discussed and summarized in https://blog.mozilla.org/security/files/2015/04/CNNIC-MCS.pdf . What are the triggers to prevent good faith misinterpretations resulting in the same situation?

--
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%2B1gtaYk2pg9tO%3Dfti_7qDWGz9tfe9s1135OqHH-cKXJ4fye%2BQ%40mail.gmail.com.

[Ben Wilson]

Hi all,

We think we have addressed all of your comments in edits that we've made to the following two documents:

Proposed edits to MRSP section 8.4 -

https://docs.google.com/document/d/1MY_0t-gOhhvP_D0YbhOHf0HstLds2bXFSDJXaOuP8U0

Wiki page edits -

https://docs.google.com/document/d/1duMqTzx32bfgzQndAy2MfHrx498Y3gxuS6zz6nASL48

I will be making corresponding changes in Github and the wiki page tomorrow.

Thanks for your input and suggestions.

Ben

[Ben Wilson]

Please see:  https://github.com/BenWilson-Mozilla/pkipolicy/commit/17e9c335801a71a94e98eb80c01fc8d0710b772e and https://wiki.mozilla.org/CA/External_Sub_CAs (which I'm cleaning up after moving it from here: https://docs.google.com/document/d/1duMqTzx32bfgzQndAy2MfHrx498Y3gxuS6zz6nASL48).

[Ryan Sleevi]

I think these look great Ben. Thanks for being flexible.

To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtaaDRVXDo0yXSW5nEzdXEA8-hFupmnRX7F87Ztb-QWi92Q%40mail.gmail.com.