Re: Policy 2.6 Proposal: Define/clarify policy for transfer of intermediate CA certificates
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 On Tue, Apr 24, 2018 at 6:02 PM, Wayne Thayer wrote: > On Tue, Apr 24, 2018 at 9:21 AM, Ryan Sleevi wrote: > >> >> >> On Mon, Apr 23, 2018 at 6:12 PM, Wayne Thayer via dev-security-policy < >> dev-security-policy@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. >> >> 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, > > 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," >> >> > ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Policy 2.6 Proposal: Define/clarify policy for transfer of intermediate CA certificates
On Tue, Apr 24, 2018 at 9:21 AM, Ryan Sleevi wrote: > > > On Mon, Apr 23, 2018 at 6:12 PM, Wayne Thayer via dev-security-policy < > dev-security-policy@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. > > 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, 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," > > ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Policy 2.6 Proposal: Define/clarify policy for transfer of intermediate CA certificates
On Mon, Apr 23, 2018 at 6:12 PM, Wayne Thayer via dev-security-policy < dev-security-policy@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," ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Policy 2.6 Proposal: Define/clarify policy for transfer of intermediate CA certificates
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 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 > > ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
