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
