On Fri, Mar 23, 2018 at 11:34 AM, Wayne Thayer via dev-security-policy <[email protected]> wrote: > Recently I've received a few questions about audit requirements for > subordinate CAs newly issued from roots in our program. Mozilla policy > section 5.3.2 requires these to be disclosed "within a week of certificate > creation, and before any such subCA is allowed to issue certificates.", but > says nothing about audits. > > The fundamental question is 'when must a new subCA be audited?' It is clear > that the TSP's [1] next period-of-time statement must cover all subCAs, > including any new ones. However, it is not clear if issuance from a new > subCA is permitted prior to being explicitly included in an audit. > > I believe that it is common practice for TSPs to begin issuing from new > subCAs prior to inclusion in an audit. This practice is arguably supported > by paragraph 3 of BR 8.1 which reads: > > If the CA has a currently valid Audit Report indicating compliance with an >> audit scheme listed in Section 8.1, then no pre-issuance readiness >> assessment is necessary. >> > > When disclosing a new subCA, the TSP can select "CP/CPS same as parent" and > "Audits same as parent" in CCADB to indicate that the same policies apply > to the new subordinate as to the root. > > This issue was raised at the CA/Browser Forum meeting in October 2016 [2]. > > Three options have been proposed to resolve this ambiguity: > 1. Permit a new subCA to be used for issuance prior to being listed on an > audit report. > 2. Require the TSP to attest that the new subCA complies with a set of > existing policies prior to issuance [3]. > 3. Require an audit report (point-in-time or period-of-time) covering the > new subCA before any issuance (possibly with an exception for test > certificates or certificates required for audit purposes). > > Please consider these options in the context of a TSP with a current audit > for the parent root that has issued a new subCA, and for which the new > subCA is operating under existing policies and in an existing operational > environment. If this is not the case, I would propose that a new audit > covering the subCA be required.
Unsurprisingly, I support option #2. However I think is it important that there are three distinct things that need to be covered: 1) Key generation for the new CA 2) Assertion of controls for the new CA 3) Issuance of a CA certificate, by an existing trusted CA, that names the new CA as the subject I does make sense to allow a slight delay in disclosure such that a single ceremony can be used to generate the key and issue a CA certificate, but a week seems plenty generous. Thanks, Peter _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
