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 <[email protected]> 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 [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
