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. This is #32 on the policy issues list [4]. I would like to request everyone's input on this topic. Based on our discussion, I may propose that we address this issue in policy version 2.6. - Wayne [1] To avoid confusion, I've chosen to use the term Trust Service Provider (TSP) to refer to the CA organization. [2] https://cabforum.org/2016/10/19/2016-10-19-20-f2f-meeting- 39-minutes/#Disclosure-of-Subordinate-CAs <https://cabforum.org/2016/10/19/2016-10-19-20-f2f-meeting-39-minutes/#Disclosure-of-Subordinate-CAs> [3] https://cabforum.org/pipermail/public/2016-September/008464.html [4] https://github.com/mozilla/pkipolicy/issues/32 <https://github.com/mozilla/pkipolicy/issues/32> _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
