Both :) Having a new audit per online CA is going to be very expensive and cause TSPs heavily limit the number of online CAs they have. Additionally all of these would be point-in-time audits, which only report on design of controls. Assuming the design is consistent between CAs, then there is no value in having additional audit reports.
However I do think there is value in having the CA provide a statement that the same controls will apply to the new CA and commit to including the CA in the next audit. Otherwise it could be over a year before it is noted that the CA does not have adequate controls. The "same audit as parent" does not make sense for new CAs, as the new CA is not included in the audit scope. I'm sure automated audit report processing will notice this and throw an error once it is online. On Mon, Mar 26, 2018 at 9:24 AM, Wayne Thayer <[email protected]> wrote: > 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 <[email protected]> wrote: >> >> 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
