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%2B1gtaYyT1EtnBAsTXoNXBrCUniDV5deq9Hd4a_paEU4DYmcWA%40mail.gmail.com.
