On Tue, Apr 30, 2019 at 11:49 AM Fotis Loukos <fot...@ssl.com> 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 <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'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 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. > 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. 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. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
