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
The two questions are related, with 2) obviously being a subset of 1). It's also possible we might decide that for some certificates, some subset of the Mozilla policy applies, but not all of it. I'm not even sure how best to frame this discussion, so let's have a go from this angle, and if it runs into the weeds, we can try again another way. The goal of scoping the Mozilla policy is, to my mind, to have Mozilla policy sufficiently broadly applicable that it covers all publicly-trusted certs and also doesn't leave unregulated sufficiently large number of untrusted certs inside publicly-trusted hierarchies that it will hold back forward progress on standards and security. The goal of CCADB disclosure is to see what's going on inside the WebPKI in sufficient detail that we don't miss important things. Yes, that's vague. Here follow a list of scenarios for certificate issuance. Which of these situations should be in full Mozilla policy scope, which should be in partial scope (if any), and which of those should require CCADB disclosure? Are there scenarios I've missed? A) Unconstrained intermediate AA) EE below B) Intermediate constrained to id-kp-serverAuth BB) EE below C) Intermediate constrained to id-kp-emailProtection CC) EE below D) Intermediate constrained to anyEKU DD) EE below E) Intermediate usage-constrained some other way EE) EE below F) Intermediate name-constrained (dnsName/ipAddress) FF) EE below G) Intermediate name-constrained (rfc822Name) GG) EE below H) Intermediate name-constrained (srvName) HH) EE below I) Intermediate name-constrained some other way II) EE below If a certificate were to only be partially in scope, one could imagine it being exempt from one or more of the following sections of the Mozilla policy: * BR Compliance (2.3) * Audit (3.1) and auditors (3.2) * CP and CPS (3.3) * CCADB (4) * Revocation (6) It's also further possible that BR Compliance could be split, requiring compliance to some parts of the BRs but not others. So this is a complicated question! One reasonable enquiry would be: what is the status quo? I _think_ it's as follows: 1) Applicability (Mozilla Root Store Policy section 1.1): all except E), EE), I) and II), but only those EE certs with no EKU, or at least one of serverAuth, emailProtection or anyEKU. 2) Disclosure (CCADB Common Policy section 4): A), B), D), possibly H) and I) depending on EKU. Is that right? Gerv _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
