From:  Fotis Loukos <fotisl@ssl.com>
Date:  30 Apr 2019 23:49:53 Hong Kong Time
Newsgroup:  news.mozilla.org/mozilla.dev.security.policy
Subject:  

Re: Policy 2.7 Proposal: Exclude Policy Certification Authorities from EKU Requirement

NNTP-Posting-Host:  63.245.210.105

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 <
>>> 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: fotisl@ssl.com
w: https://www.ssl.com