On 19/05/17 14:47, Gervase Markham wrote: > We need to have a discussion about the appropriate scope for: > > 1) the applicability of Mozilla's root policy > 2) required disclosure in the CCADB
I've now reviewed the previous discussion we had on this topic, here: https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/ZMUjQ6xHrDA/ySofsF_PAgAJ In it, Ryan writes: "This wording implies that technically constrained sub-CAs, from a Mozilla Policy standpoint, are not required to adhere to the Baseline Requirements." I don't believe that's true now, if it ever was. I think the scope statement in policy 2.4.1 section 1.1 and the BR applicability statement in section 2.3 makes it clear that Mozilla policy applies, and Mozilla policy expects the BRs to apply, to all certificates in publicly-trusted hierarchies except those which are constrained to not issue/be used for SSL or email. However, that discussion suggests to me that we should do the following: * Given CT, and the need within it to disclose TCSCs, the privacy argument seems to have been abandoned. So I think it's reasonable to also require disclosure of TCSCs themselves. This allows checking that they are indeed appropriately constrained. The obvious place to put them is the CCADB but it's possible we could consider something CT-based, as we don't need to track the paperwork the CCADB stores (audits, etc.). * So the options for intermediate certs would change from "(technically constrained) or (publicly disclosed and audited)" to "(publicly disclosed) and (technically constrained or fully audited)". * In terms of my original message, this would mean adding type F) to the CCADB disclosure list. * We should consider going above and beyond the BRs by tweaking the parameters for the section 8.7 audit of the certs below a TCSC. At the moment, it's "the greater of one certificate or at least three percent of the Certificates issued". I think it should be more like: MAX(MIN(5 certificates, all certificates), 3% of certificates). In other words: Issued Audited 0 0 1 1 .... 5 5 6 5 .... 166 5 167 6 .... Auditing just a single certificate (currently OK up until 33 are issued) makes it too easy to overlook problems when volumes are small. Comments? Gerv _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
