Re: Policy 2.6 Proposal: Define/clarify policy for transfer of intermediate CA certificates

[Wayne Thayer]

I'm re-sending this with the subject tagged as a 'policy 2.6 proposal' in
case anyone missed it the first time.

I am leaning toward option 2 as the best solution. The scope of section 8
could be updated to state the following:

CAs SHOULD NOT assume that trust is transferable. All CAs whose
certificates are included in Mozilla's root program MUST notify Mozilla if:

* ownership or control of the CA’s included certificate(s) changes; or,
* the CA creates an unconstrained intermediate certificate as defined in
section 5.3.2 that is controlled by another organization; or,
* ownership or control of the CA's unconstrained intermediate
certificate(s) changes; or,
* ownership or control of the CA’s operations changes; or,
* there is a material change in the CA's operations.


This would then explicitly require CAs who create or transfer an
unconstrained intermediate certificate to a 3rd party to obtain approval
and meet the other requirements outlined in section 8.

I would appreciate everyone's comments on this proposed change.

- Wayne

On Tue, Apr 17, 2018 at 11:42 AM, Wayne Thayer <wth...@mozilla.com> wrote:

> This issue was brought up in the thread that kicked off the 2.6 root store
> policy update [1]. Mozilla policy section 5.3.2 requires CAs to disclose
> new unconstrained intermediate CA certificates within one week of creation.
> Section 8 covers [in my opinion] transfers of roots but not intermediates.
> This leaves a loophole for a CA to create a new intermediate CA
> certificate, then transfer it without notice or approval. This problem also
> applies to cross-signatures from one CA to another.
>
> I am aware of three potential solutions:
>
> 1. In section 5.3.2, require CAs to also disclose a change in the
> ownership or control of an unconstrained intermediate CA certificate within
> one week of the change.
>
> 2. Modify section 8 to explicitly include transfers of trust via
> intermediate CA certificates and cross signatures. Under section 8.1, this
> would require notice and approval:
>
> If the receiving or acquiring company is new to the Mozilla root program,
>> there MUST be a public discussion regarding their admittance to the root
>> program, which Mozilla must resolve with a positive conclusion before
>> issuance is permitted.
>>
> 3. Require organizations that are receiving subordinate CA certificates to
> go through the whole Mozilla inclusion process as if they were applying for
> a new root.
>
> I would appreciate everyone's input on this topic.
>
> This is: https://github.com/mozilla/pkipolicy/issues/122
>
> [1] https://groups.google.com/d/msg/mozilla.dev.security.policy/
> xGGGaI1_uo0/POMANRWRAAAJ
> -------
>
> This is a proposed update to Mozilla's root store policy for version
> 2.6. Please keep discussion in this group rather than on GitHub. Silence
> is consent.
>
> Policy 2.5 (current version):
> https://github.com/mozilla/pkipolicy/blob/2.5/rootstore/policy.md
>
>

[Ryan Sleevi]

On Mon, Apr 23, 2018 at 6:12 PM, Wayne Thayer via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> I'm re-sending this with the subject tagged as a 'policy 2.6 proposal' in
> case anyone missed it the first time.
>
> I am leaning toward option 2 as the best solution. The scope of section 8
> could be updated to state the following:
>
> CAs SHOULD NOT assume that trust is transferable. All CAs whose
> certificates are included in Mozilla's root program MUST notify Mozilla if:
>
> * ownership or control of the CA’s included certificate(s) changes; or,
> * the CA creates an unconstrained intermediate certificate as defined in
> section 5.3.2 that is controlled by another organization; or,
> * ownership or control of the CA's unconstrained intermediate
> certificate(s) changes; or,
> * ownership or control of the CA’s operations changes; or,
> * there is a material change in the CA's operations.
>
>
> This would then explicitly require CAs who create or transfer an
> unconstrained intermediate certificate to a 3rd party to obtain approval
> and meet the other requirements outlined in section 8.
>
> I would appreciate everyone's comments on this proposed change.
>

Apologies if I'm missing something, but I'm curious how this would cover
the case of:

Org A - "TSP" operating a singular root certificate in the Mozilla program
Org B - "TSP" operating a single signed intermediate from Org A's Root
Certificate
Org C - "TSP" operating a single signed intermediate from Org B's
"Intermediate Certificate"
Org D - A new TSP

My understanding is that the proposed language would address the situation
if Org B transferred control to org D, but I'm struggling to see where/how
it would require Org C to be subject to that if they transferred to Org D.

The ambiguity that I struggle with comes from "control of the CA's" (in the
third bullet) that seems subject to "All CAs whose certificates are
included in Mozilla's root program" in the intro. It would seem it would
only bind the Org A relationship, not Org B's.

In this regard, 5.3.2 is slightly less ambiguous, as it governs "All
certificates that are capable of being used to issue new certificates, and
which directly or transitively chain to a certificate included in Mozilla’s
CA Certificate Program,"

[Wayne Thayer]

> Good point. How about combining the two bullets from my earlier proposal
as follows:

CAs SHOULD NOT assume that trust is transferable. All CAs whose
certificates are included in Mozilla's root program MUST notify Mozilla if:

* an organization other than the CA obtains control of an unconstrained
intermediate certificate (as defined in section 5.3.2) that directly or
transitively chains to the CA's included certificate(s); or,

[Wayne Thayer]

Seeing no additional comments, I've gone ahead and added this change to the
2.6 branch of the policy:
https://github.com/mozilla/pkipolicy/commit/7a33f1d065733c19b6030261c1a11f860c30dc10

- Wayne