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
