On 30/4/19 6:34 μ.μ., Ryan Sleevi via dev-security-policy wrote:
> On Tue, Apr 30, 2019 at 8:51 AM Fotis Loukos 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 <
>>> firstname.lastname@example.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
>>>> to exclude cross certificates . Last month, an issue  was filed
>>>> requesting that we add "Policy Certification Authorities" (PCAs) as
>>>> 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
>>>> not in theory weaken it. However, I'm not aware of any way to
>>>> 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
>>>> an architecture that should be abandoned in favor of x509v3 certificate
>>>> 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,
>>> 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
>>> EV, OV, DV S/MIME issuing intermediates, using the Certificate Policies
>>> 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
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
> (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
> dev-security-policy mailing list
Fotis Loukos, PhD
Director of Security Architecture