On Tue, Apr 30, 2019 at 8:51 AM Fotis Loukos <fot...@ssl.com> wrote: > 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. >
Can you explain to me why you believe this is prohibited? The second model is the model that is permitted - the first model is, as you note, expressly forbidden by policy. I suppose it wasn't clear that the , was separating out a list of intermediates. That is, in the 'second' model, you'd construct the following: (Root, no policies / any policy) -> (TLS intermediate) -> (EV intermediate) -> (EV TLS Leaf) (Root, no policies / any policy) -> (TLS intermediate) -> (OV intermediate) -> (OV TLS leaf) (Root, no policies / any policy) -> (TLS intermediate) -> (DV intermediate) -> (DV TLS leaf) (Root, no policies / any policy) -> (S/MIME intermediate) -> (EV intermediate) -> (EV S/MIME leaf) ... etc This is *highly* desirable and strongly beneficial to security than a model which is expressly forbidden in the current policy, which is (Root, no policies / any policy) -> (EV intermediate) -> (TLS intermediate) -> (EV TLS leaf) (Root, no policies / any policy) -> (EV intermediate) -> (S/MIME intermediate) -> (EV S/MIME leaf) That model creates significant risk to users, because that EV intermediate is capable of issuing both, subject to the union of policies, needs to be audited under both policies, and regularly we see issues with CA's thinking that their requirements on S/MIME don't apply to TLS. > > 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. > I disagree with this conclusion. I believe it demonstrably introduces more risk to have intermediates that are jointly capable of issuing for multiple purposes, as has been shown repeatedly in past issuance issues and "not intended" litigation. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
