Peter, Are you advocating for option #2 (TSP self-attestation) because you think that option #3 (audit) is unreasonable, or because you believe there is a benefit to Mozilla's users in a self-attestation beyond what we get from the existing requirement for CCADB disclosure?
On Fri, Mar 23, 2018 at 6:18 PM, Peter Bowen <pzbo...@gmail.com> wrote: > On Fri, Mar 23, 2018 at 11:34 AM, Wayne Thayer via dev-security-policy > <dev-security-policy@lists.mozilla.org> 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 dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
