In https://bugzilla.mozilla.org/show_bug.cgi?id=1311200 , Kathleen suggested I bring the broader discussion to mozilla.dev.security.policy, so this is that thread.
At present, there's an element of inconsistency between the BRs and Mozilla Policy that leads to some confusion. With respect to Mozilla's current policies, https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/ : 8. All certificates that are capable of being used to issue new certificates, and which directly or transitively chain to a certificate included in Mozilla’s CA Certificate Program, MUST be operated in accordance with Mozilla’s CA Certificate Policy and MUST either be technically constrained or be publicly disclosed and audited. This wording implies that technically constrained sub-CAs, from a Mozilla Policy standpoint, are not required to adhere to the Baseline Requirements. However, the Baseline Requirements have a different set of criteria. In Section 8.1 of the BRs (v1.4.1, https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.4.1.pdf ), it states: Certificates that are capable of being used to issue new certificates MUST either be Technically Constrained in line with section 7.1.5 and audited in line with section 8.7 only, or Unconstrained and fully audited in line with all remaining requirements from this section Section 8.7 reads: During the period in which a Technically Constrained Subordinate CA issues Certificates, the CA which signed the Subordinate CA SHALL monitor adherence to the CA’s Certificate Policy and the Subordinate CA’s Certification Practice Statement. On at least a quarterly basis, against a randomly selected sample of the greater of one certificate or at least three percent of the Certificates issued by the Subordinate CA, during the period commencing immediately after the previous audit sample was taken, the CA shall ensure all applicable CP are met. That is, according to the BRs, the issuer of a technically constrained subordinate CA has a BR-obligation to ensure that their TCSCs are adhering to the BRs and the issuing CA's policies and practices, as well as conduct a sampling audit quarterly. The element of inconsistency is what the expectations of Mozilla are, if the issuing CA, which has a BR obligation to monitor their TCSCs, and which Mozilla expects to adhere to the BRs, does not perform this task, and the TCSC does not adhere to the issuing CA's (which is subject to Mozilla's requirements) policy. On one hand, this is a BR violation by the issuing CA, and Mozilla nominally cares about BR violations for CAs subject to its requirements. On the other hand, the root cause is due to a TCSC, for which Mozilla policy explicitly carves out. Given that the issuing CA may be subjected to a qualified audit finding, on the basis of the the actions of the TCSC, it may be useful to understand Mozilla's position on this, as well as determine what guidance, if any, should be provided to auditors and to the CA/Browser Forum about this apparent disagreement between Mozilla Policy and the Baseline Requirements. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
