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/CAErg%3DHEwZSYj961Hw8kfM1kQ861bn%2BejTrPU-qM4f_18i7rrZw%40mail.gmail.com.
