I'd like to revisit this topic because I see it as a significant change and am surprised that it didn't generate any discussion.
Taking a step back, a change [1] to notification requirements was made last year to require CAs that are signing unconstrained subordinate CAs (including cross-certs) controlled by a different organization to notify Mozilla. We have received few, if any, notifications of this nature, so I have to wonder if CAs are adhering to this requirement. This requirement applies as follows: an organization other than the CA obtains control of an unconstrained > intermediate certificate (as defined in section 5.3.2 of this policy) that > directly or transitively chains to the CA's included certificate(s); > Is the "obtains control" language being interpreted to mean that this only applies when control of the private keys change, and not when a CA signs a key controlled by a different organization? I believe the intent is for this to apply in both situations - otherwise it is trivial to bypass. The new change [2] proposed for version 2.7 of our policy goes one step further and places transfers and signings of unconstrained subordinate CAs clearly in the scope of section 8.1, including the following language: If the receiving or acquiring company is new to the Mozilla root program, > it must demonstrate compliance with the entirety of this policy and there > MUST be a public discussion regarding their admittance to the root program, > which Mozilla must resolve with a positive conclusion in order for the > affected certificate(s) to remain in the root program. If the entire CA > operation is not included in the scope of the transaction, issuance is not > permitted until the discussion has been resolved with a positive conclusion. That means any organization "new to the Mozilla root program" for which a CA signs an unconstrained subordinate CA or cross-cert must go through an approval process including a public discussion before issuing certificates in order to comply with this policy. It also means that we need to decide what "new to the Mozilla root program" means. Organizations that control unconstrained subordinate CAs have not been considered members of the program in the past, so it's easy to argue that every such organization will be "new to the Mozilla root program" if/when this policy goes into effect. However, it may be more practical to "grandfather in" organizations that are currently in control of unconstrained subordinate CAs. This also raises the question of what it means to "demonstrate compliance with the entirety of this policy". Section 8.1 has historically applied to companies acquiring root CAs and we have not required them to go through the entire inclusion process - only a public discussion. Should that same interpretation apply to unconstrained subordinate CA? Before proposing any changes, I'd like to ask for everyone's input on these and any other concerns stemming from this policy proposal. - Wayne [1] https://github.com/mozilla/pkipolicy/commit/7a33f1d065733c19b6030261c1a11f860c30dc10 [2] https://github.com/mozilla/pkipolicy/commit/175aed5f145ae0f29735a13801a5639e70f1f0a8 On Fri, May 10, 2019 at 1:58 PM Wayne Thayer <wtha...@mozilla.com> wrote: > Having received no comments on these proposed changes, I plan to include > them in version 2.7 of our policy. > > - Wayne > > On Fri, Apr 19, 2019 at 11:55 AM Wayne Thayer <wtha...@mozilla.com> wrote: > >> Ryan Sleevi made the following proposal: >> >> Issue #122 [1] previously discussed Section 8 in the context of >>> subordinate CAs, with a change [2] being made to include subordinate CAs >>> (in the context of Section 5.3.2) within scope of notification requirements. >>> >>> However, as presently worded, it's ambiguous as to whether or not >>> Sections 8.1 through 8.3 also apply to subordinate CAs, or whether the only >>> disclosure required is upon the initial introduction of the subordinate. >>> This confusion results from language such as in Section 8.1, "or when an >>> organization buys the private key of a certificate in Mozilla's root >>> program", implying that private keys which transitively chain to a root >>> certificate within Mozilla's program are exempt from such requirements. >>> >>> This ambiguity creates incentives for situations such as cross-signing >>> CAs that might otherwise or have been otherwise rejected from direct >>> inclusion within the Mozilla program. It further creates issues with >>> respect to the supervision of audits and auditors. >>> >>> While it is true that the signing CA accepts the risk that an >>> unfavorable verdict on the subordinate may impact the root, the cost of >>> such a decision is primarily borne by Mozilla and the broader community, in >>> that they are responsible for the collateral ecosystem challenges and >>> devising appropriate solutions. This has been demonstrated, for example, >>> through the discussion of Symantec issues [3]. >>> >>> Because Mozilla and the community bear significant cost, especially as >>> more time passes and more certificates are issued, the following changes >>> are suggested: >>> >>> 1. Align Section 8, and its subsections, with language similar to >>> that of Section 3.1.2.1. That is, that the policy is applicable to a CA >>> and >>> all subordinate CAs technically capable of issuing (server or e-mail) >>> certificates >>> 2. With respect to Section 8.1, extend the requirements of the last >>> paragraph to the issuance of subordinate CA certificates. Namely, if the >>> private key is in possession of an entity that is new to the Mozilla root >>> program, or subject to a CP or CPS that is new to the Mozilla Root >>> Program, >>> that prior to the issuance of such a certificate, there be a public >>> discussion that results in a favorable conclusion. >>> >>> With the current policy as written, an existing/included root CA that >>> plans to exit the CA business might be prohibited (by virtue of Section >>> 8.1) from selling the business or (by virtue of Section 8.3) from >>> transferring the private key material. However, they are fully permitted to >>> cross-certify a new 'root' and then proverbially close up shop - with no >>> consideration for if their root gets removed as a consequence. These are >>> the same set of concerns that led to the introduction of Section 8, but >>> today exist due to the ambiguity with respect to the subsections. >>> >> >> I've proposed a fix for this issue: >> https://github.com/mozilla/pkipolicy/commit/175aed5f145ae0f29735a13801a5639e70f1f0a8 >> It also attempts to clarify the applicability of section 8.3 as "only" >> when section 8.1 and/or section 8.2 also apply. >> >> This is https://github.com/mozilla/pkipolicy/issues/169 and >> https://github.com/mozilla/pkipolicy/issues/140 >> >> I will greatly appreciate everyone's input on this topic. In particular, >> I would like to hear from CAs that would be affected by the requirement for >> any new subordinate CAs to go through a public discussion before issuing >> certificates, with the outcome being positive or else the subordinate CA >> certificate will be added to OneCRL (section 8.1). >> >> - Wayne >> >> [1] https://github.com/mozilla/pkipolicy/issues/122 >> [2] >> https://github.com/mozilla/pkipolicy/commit/7a33f1d065733c19b6030261c1a11f860c30dc10 >> [3] https://wiki.mozilla.org/CA:Symantec_Issues >> > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
