I think these look great Ben. Thanks for being flexible. On Thu, Apr 7, 2022 at 7:03 PM Ben Wilson <[email protected]> wrote:
> 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 > <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtaaDRVXDo0yXSW5nEzdXEA8-hFupmnRX7F87Ztb-QWi92Q%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/CAErg%3DHEMkVML0UR%3DwUzZU6rh4jp32%2BxRXJ4kRHAW6vnFXQ_k_w%40mail.gmail.com.
