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 ).
On Wed, Apr 6, 2022 at 5:01 PM Ben Wilson <[email protected]> wrote: > 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 > > On Wed, Apr 6, 2022 at 8:02 AM Ryan Sleevi <[email protected]> wrote: > >> 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? >> >> On Thu, Mar 31, 2022 at 11:48 PM Ben Wilson <[email protected]> wrote: >> >>> 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 >>> >>> -- >>> 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%2B1gtaYk2pg9tO%3Dfti_7qDWGz9tfe9s1135OqHH-cKXJ4fye%2BQ%40mail.gmail.com >>> <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtaYk2pg9tO%3Dfti_7qDWGz9tfe9s1135OqHH-cKXJ4fye%2BQ%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%2B1gtaaDRVXDo0yXSW5nEzdXEA8-hFupmnRX7F87Ztb-QWi92Q%40mail.gmail.com.
