On 30/4/19 6:34 μ.μ., Ryan Sleevi via dev-security-policy wrote: > 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.
As I said, this is prohibited by the Root Store Policy using a single SubCA. If that SubCA was to issue a TLS and an S/MIME intermediate, it would need to either: - Not include an EKU extension -> prohibited by the clause "MUST contain an EKU extension" - Include the anyExtendedKeyUsage KeyPurposeId -> prohibited by the clause "MUST NOT include the anyExtendedKeyUsage KeyPurposeId" - Include both the id-kp-serverAuth and id-kp-emailProtection KeyPurposeIds -> prohibited by the clause "MUST NOT include both the id-kp-serverAuth and id-kp-emailProtection KeyPurposeIds in the same certificate." I don't know of any other possible configurations that would allow this. Please let me know if this can be solved in some other way. > > 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. Just to clarify, the EV intermediate is not issuing end-entity certificates. How is this different from auditing a Root CA under both policies? Or how is it different from auditing a Sub CA issued before 2019/01/01 under both policies? > > >> >> 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. Can you please point me to one of those issues where a SubCA not issuing end entity certificates, but having EKU constrained intermediates led to an issue? Best regards, Fotis > _______________________________________________ > 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
