Hello, On 30/4/19 6:59 μ.μ., Ryan Sleevi via dev-security-policy wrote: > On Tue, Apr 30, 2019 at 11:49 AM Fotis Loukos <[email protected]> wrote: > >> On 30/4/19 6:34 μ.μ., Ryan Sleevi via dev-security-policy wrote: >>> On Tue, Apr 30, 2019 at 8:51 AM Fotis Loukos <[email protected]> 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 < >>>>> [email protected]> 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'm afraid we're saying the same thing, so I'm not sure where the confusion > is. > > It would appear you're interpreting "(TLS, S/MIME "policy" intermediates, > using EKU)" as referring to a single certificate, wheras I'm trying to > clearly specify (as later provided) that this is not, and is in fact two > different certificates, each constrained by EKU to a singular, specific > purpose. > > This is desirable. >
I am just arguing that there is no risk involved in having a single certificate. I do agree that the model you proposed with the two certificates is a model that can be used right now, but I do not see any additional risks by having a single certificate. > >>> 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. >> >> > For clarity sake, this is the model that is prohibited under the current > policy. > > >> Just to clarify, the EV intermediate is not issuing end-entity >> certificates. > > > Correct, under the currently-prohibited model, this is the case. > > >> How is this different from auditing a Root CA under both policies? >> > > Among other things, the Root CA is permitted to be offline, but the EV > intermediate is not. This is a difference at the specific requirements for the particular CAs, and not a difference on the policies the CAs are audited against. I thought that your point is that that model creates a significant risk to the users because it is subject to the union of policies and needs to be audited under both policies. The fact that a CA is audited against a single or multiple policies is semantically different to the content of the policies themselves. > > >> Or how is it different from auditing a Sub CA issued before 2019/01/01 >> under both policies? > > > It is this previously-permitted, now forbidden, aspect of policy that was > the intentional specification of policy. Folks would argue that the EV > intermediate - capable of issuing TLS certificates - wasn't "intended" to > be used as such, and thus would exclude it from audits or complying with > the BRs, or any other number of divergent, non-compliant behaviours. Well, I totally agree that this interpretation is really, REALLY, bad, and I would never support something like this. I really don't think that any auditors would actually agree with this since it creates a huge risk to the ecosystem and as far as I'm concerned, it is clear that such CAs are in scope. However, I wouldn't object to adding that such SubCAs are subject to both policies, if that would address your concerns. > > The current policy ensures that there's technical restrictions on this, and > defines them in such a way that the permitted hierarchy is the desired > hierarchy, not only for matters of assessing compliance, but of reducing > risk to users. You are mentioning the risk to the users, and in your previous email you mentioned that there were issues in the past. I would appreciate it if you could please point me to a single occasion where a SubCA not issuing end entity certificates, but having EKU constrained intermediates led to an issue. Even a theoretical example would be enough. Best regards, Fotis > _______________________________________________ > dev-security-policy mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-security-policy > -- Fotis Loukos, PhD Director of Security Architecture SSL Corp e: [email protected] w: https://www.ssl.com _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
