On Fri, Apr 26, 2019 at 7:02 PM Wayne Thayer via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote:
> In version 2.6 of our Root Store Policy, we added the requirement to > section 5.3 that intermediate certificates contain an EKU and separate > serverAuth and emailProtection uses. Version 2.6.1 updated the requirement > to exclude cross certificates [1]. Last month, an issue [2] was filed > requesting that we add "Policy Certification Authorities" (PCAs) as another > exception. > > PCAs are described in RFC 5280 as a CA certificate that is only used to > issue other CA certificates, so excluding PCAs from this requirement would > not in theory weaken it. However, I'm not aware of any way to technically > enforce that PCAs not issue end-entity certificates, and allowing more > exceptions would seem to make this policy more difficult to enforce. In > addition, RFC 5280 section 3.2 appears to reference PCAs as an example of > an architecture that should be abandoned in favor of x509v3 certificate > extensions: > > With X.509 v3, most of the requirements addressed by RFC 1422 can be > addressed using certificate extensions, without a need to restrict > the CA structures used. In particular, the certificate extensions > relating to certificate policies obviate the need for PCAs... > > This is https://github.com/mozilla/pkipolicy/issues/172 > > I will appreciate everyone's input on this proposal. > TL;DR: I do not support this change. This appears to highlight a tension between Mozilla Policy and (possible) ways to design a PKI. Consider the example of a CA that produces EV, OV, and DV certificates, for use in both TLS and S/MIME. One hierarchy would have (Root, no policies/any policy) -> (EV, OV, DV PCAs, using the Certificate Policies extension to constrain the policies) -> (TLS, S/MIME issuing intermediates, using EKU) -> Leaf Another hierarchy would be (Root, no policies/any policy) -> (TLS, S/MIME "policy" intermediates, using EKU) -> (EV, OV, DV TLS issuing intermdiates, EV, OV, DV S/MIME issuing intermediates, using the Certificate Policies to constrain the policies) It's unclear to me the benefit of the former design over the latter, for either the CA or for relying parties. On the other hand, the benefits are clearer for the latter - in which the S/MIME vs TLS split happens as early as possible. This approach reduces the scope of audits: in the former design, the PCAs need to be covered by both TLS and S/MIME applicable audits, while the latter allows cleaving the S/MIME CAs from the scope of the TLS audits. Similarly, this latter approach, reflected in the current language, also reduces the scope of risk - if an EV PCA issues an inappropriate S/MIME issuing intermediate, revoking that EV PCA would also revoke all EV TLS certificates under the PCA model, while under the current model, the technical constraints of the TLS "policy" intermediate reduce the risk of misissuing an S/MIME intermediate under that hierarchy. As it's unclear to me the benefit of accommodating the PCAs, because as you note, it's more complexity to the policy, and because it seems to be systemically more riskier for end-users and more expensive for CAs, I don't think we should support modifying the policy. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
