Hello Ryan, On 29/4/19 5:20 μ.μ., Ryan Sleevi via dev-security-policy wrote: > 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)
I would be glad to implement the second model you are proposing, but AFAICT this is prohibited by the Root Store Policy using a single SubCA. More precisely, section 5.3 of the Root Store Policy mentions: Intermediate certificates created after January 1, 2019, with the exception of cross-certificates that share a private key with a corresponding root certificate: MUST contain an EKU extension; and, MUST NOT include the anyExtendedKeyUsage KeyPurposeId; and, * MUST NOT include both the id-kp-serverAuth and id-kp-emailProtection KeyPurposeIds in the same certificate. In your example, the TLS, S/MIME "policy" intermediates have to be different since they cannot include both the id-kp-serverAuth and id-kp-emailProtection EKUs. I do not think that having a single CA for this will introduce any risks. To summarize, I agree with the second model you are proposing, but I do not think that a single SubCA under the Root will introduce any additional risks compared to different SubCAs depending on the usage. Regards, Fotis > > 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 > -- Fotis Loukos, PhD Director of Security Architecture SSL Corp e: fot...@ssl.com w: https://www.ssl.com _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
