Policy 2.6 Proposal: Require separate intermediates for different usages (e.g. server auth, S/MIME)

[Wayne Thayer]

This proposal is to require intermediate certificates to be dedicated to
specific purposes by EKU. Beginning at some future date, all newly created
intermediate certificates containing either the id-kp-serverAuth or
id-kp-emailProtection EKUs would be required to contain only a single EKU.

Arguments for this requirement are that it reduces risk of an incident in
which one type of certificate affecting another type, and it could allow
some policies to be restricted to specific types of certificates.

It was pointed out that Microsoft already requires dedicated intermediates
[1].

I would appreciate everyone's input on this topic.

I suspect that it will be tempting to extend this discussion into
intermediate rollover policies, but I would remind everyone of the prior
inconclusive discussion on that topic [2].

This is: https://github.com/mozilla/pkipolicy/issues/26

[1] https://aka.ms/rootcert
[2]
https://groups.google.com/d/msg/mozilla.dev.security.policy/3NdNMiM-TQ8/hgVsCofcAgAJ
-------

This is a proposed update to Mozilla's root store policy for version
2.6. Please keep discussion in this group rather than on GitHub. Silence
is consent.

Policy 2.5 (current version):
https://github.com/mozilla/pkipolicy/blob/2.5/rootstore/policy.md

[Dimitris Zacharopoulos]

On 17/4/2018 9:24 μμ, Wayne Thayer via dev-security-policy wrote:
> This proposal is to require intermediate certificates to be dedicated to
> specific purposes by EKU. Beginning at some future date, all newly created
> intermediate certificates containing either the id-kp-serverAuth or
> id-kp-emailProtection EKUs would be required to contain only a single EKU.

We should not require a single EKU but separation of id-kp-serverAuth
and id-kp-emailProtection. This means that if an Intermediate CA
Certificate includes the id-kp-serverAuth, it MUST NOT include
id-kp-emailProtection but it MAY also include (for example) the
id-kp-clientAuth EKU.

Dimitris.

[Doug Beattie]

> -----Original Message-----
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+doug.beattie=globals...@lists.mozilla.org] On Behalf Of
> Wayne Thayer via dev-security-policy
> Sent: Tuesday, April 17, 2018 2:24 PM
> To: mozilla-dev-security-policy <mozilla-dev-security-
> pol...@lists.mozilla.org>
> Subject: Policy 2.6 Proposal: Require separate intermediates for different
> usages (e.g. server auth, S/MIME)
>
> This proposal is to require intermediate certificates to be dedicated to
> specific purposes by EKU. Beginning at some future date, all newly created
> intermediate certificates containing either the id-kp-serverAuth or id-kp-
> emailProtection EKUs would be required to contain only a single EKU.

We'll need to support a list of EKUs if this becomes a requirement. Server Auth certificates should be able to support lots of different EKUs, for example:
id-kp-serverAuth
id-kp-clientAuth
id-kp-ipsecEndSystem
id-kp-ipsecTunnel
id-kp-ipsecUser
KDC Authentication
Smart Card Logon
iPSec IKE
IKE Intermediate

> Arguments for this requirement are that it reduces risk of an incident in which
> one type of certificate affecting another type, and it could allow some
> policies to be restricted to specific types of certificates.
>
> It was pointed out that Microsoft already requires dedicated intermediates
> [1].

I agree with using dedicated intermediates, but I'd prefer that they should not be required to be EKU constrained.

> I would appreciate everyone's input on this topic.
>
> I suspect that it will be tempting to extend this discussion into intermediate
> rollover policies, but I would remind everyone of the prior inconclusive
> discussion on that topic [2].
>
> This is: https://github.com/mozilla/pkipolicy/issues/26
>
> [1] https://aka.ms/rootcert
> [2]
> https://groups.google.com/d/msg/mozilla.dev.security.policy/3NdNMiM-
> TQ8/hgVsCofcAgAJ
> -------
>
> This is a proposed update to Mozilla's root store policy for version 2.6.
> Please keep discussion in this group rather than on GitHub. Silence is consent.
>
> Policy 2.5 (current version):
> https://github.com/mozilla/pkipolicy/blob/2.5/rootstore/policy.md

> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy

[Jeremy Rowley]

If you don't specify by EKU, the exercise of determining intent becomes
impossible as illustrated by our (many) attempts to define a server cert in
CAB Forum. Better to list the EKUs allowed and not allowed in the same cert
than rely on another intent requirement.

[Wayne Thayer]

Here is a concrete proposal that addresses the concerns than have been
raised:

Add the following statement to Mozilla policy section 5.3 (Intermediate
Certificates):

Intermediate certificates created after January 1, 2019:
* 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.

Another argument in favor of (eventually) eliminating unconstrained
intermediates is that I've seen a number of CAs who believe (incorrectly)
that unconstrained intermediate CA certificates not used to issue TLS
certificates are exempt from the BRs.

Are there other arguments for or against this change?

On Tue, Apr 17, 2018 at 1:33 PM, Jeremy Rowley <jeremy...@digicert.com>
wrote:

[Jakob Bohm]

On 17/04/2018 20:24, Wayne Thayer wrote:
> This proposal is to require intermediate certificates to be dedicated to
> specific purposes by EKU. Beginning at some future date, all newly created
> intermediate certificates containing either the id-kp-serverAuth or
> id-kp-emailProtection EKUs would be required to contain only a single EKU.
>
> Arguments for this requirement are that it reduces risk of an incident in
> which one type of certificate affecting another type, and it could allow
> some policies to be restricted to specific types of certificates.
>

One case that needs to be considered is specifying a set of closely
related EKUs, which are desirable to include in the same end entity
certificate. A typical combination would be emailProtection and
clientAuth, for the same identity in the EE cert.

> It was pointed out that Microsoft already requires dedicated intermediates
> [1].
>
> I would appreciate everyone's input on this topic.
>
> I suspect that it will be tempting to extend this discussion into
> intermediate rollover policies, but I would remind everyone of the prior
> inconclusive discussion on that topic [2].
>
> This is: https://github.com/mozilla/pkipolicy/issues/26
>
> [1] https://aka.ms/rootcert
> [2]
> https://groups.google.com/d/msg/mozilla.dev.security.policy/3NdNMiM-TQ8/hgVsCofcAgAJ

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

[Wayne Thayer]

On Thu, Apr 19, 2018 at 8:40 PM, Jakob Bohm via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> On 17/04/2018 20:24, Wayne Thayer wrote:
>

>> This proposal is to require intermediate certificates to be dedicated to
>> specific purposes by EKU. Beginning at some future date, all newly created
>> intermediate certificates containing either the id-kp-serverAuth or
>> id-kp-emailProtection EKUs would be required to contain only a single EKU.
>>
>> Arguments for this requirement are that it reduces risk of an incident in
>> which one type of certificate affecting another type, and it could allow
>> some policies to be restricted to specific types of certificates.
>>
>>

> One case that needs to be considered is specifying a set of closely
> related EKUs, which are desirable to include in the same end entity
> certificate. A typical combination would be emailProtection and
> clientAuth, for the same identity in the EE cert.
>

> I believe the language I proposed takes care of this:
https://github.com/mozilla/pkipolicy/commit/1ccf31557932ede045f3c2d7bcdac533c5176f18

If there are no additional comments, I will consider this issue to be
resolved and will include this change in version 2.6 of the policy.

- Wayne

[pfuen...@gmail.com]

I think you should consider an an exception Issuing CAs including Name Constraints. This would keep allowing root signing services for corporate CAs without forcing multiple CAs.

[Wayne Thayer]

On Sun, Apr 22, 2018 at 2:56 PM, pfuentes69--- via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> I think you should consider an an exception Issuing CAs including Name
> Constraints. This would keep allowing root signing services for corporate
> CAs without forcing multiple CAs.
>

Thank you for the suggestion. It seems reasonable to me. If no one objects,
I will move the proposed language to section 5.3.2 so that it applies only
to unconstrained intermediates.

- Wayne

[Ryan Sleevi]

I'm not sure I underestand the use case. I'm hoping that they can clarify
more.

That is, it would seem valuable as part of the technical constraint
exercise to ensure the EKUs are restsricted. This is particularly true due
to how nameConstraints work - they are blacklists (effectively), rather
than whitelists, which means that combined with EKUs, they can be used for
unconstrained purposes.

Similar to the discussions regarding nameConstraints and name types, this
has the effect of discouraging the introduction of new EKUs, as such
intermediates would be unconstrained for these potential new and novel EKU
use cases.

[Wayne Thayer]

On Tue, Apr 24, 2018 at 9:24 AM, Ryan Sleevi <ry...@sleevi.com> wrote:

> I'm not sure I underestand the use case. I'm hoping that they can clarify
> more.
>

> Pedro - can you explain more about why this is important?

That is, it would seem valuable as part of the technical constraint
> exercise to ensure the EKUs are restsricted. This is particularly true due
> to how nameConstraints work - they are blacklists (effectively), rather
> than whitelists, which means that combined with EKUs, they can be used for
> unconstrained purposes.
>
> Similar to the discussions regarding nameConstraints and name types, this
> has the effect of discouraging the introduction of new EKUs, as such
> intermediates would be unconstrained for these potential new and novel EKU
> use cases.
>

> Ryan - can you explain this concern in more detail? If, for instance, the
srvName type was added for TLS certificates, new intermediates would be
required to constrain that name type due to the "fail open" nature of name
constraints. If a single intermediate contained both the serverAuth and
emailProtection EKUs, how does that make the situation worse? Is it just
that now all of the S/MIME certificates issued under the intermediate must
also expire or be replaced so that the old intermediate (without a
constraint on srvName) can be revoked?

[pfuen...@gmail.com]

With all my respects to the experts involved in this discussion, my statement is based in risk management, and I just think there's maybe no need to over-regulate name-constrained CAs, as this technique is already reducing the risks that those new rules intend to control.

Name Constraints, as used in practice, define a name span of "only allowed" DNS and Organization names, so it's not actually a blacklist, but an exclusive whitelist. We must also consider that even if not disclosed in the CCADB, when we "suffer" a Webtrust audit we are screened on the effective usage of name constraints in all issued CA Certificates, so an auditor won't accept a CA as "out of scope of the BR audit" if it's merely whitelisting certain names or merely blacklisting certain other names... but effectively limiting the activity of a CA to a closed set of names, which BTW are vetted prior to execute the CA ceremony.

Therefore, my statement is made considering the corporate customers that want a root signing service for their own CA, sometimes linked to an Active Directory and aiming to fulfill the needs of the company for personal and server certificates in the domains they own or are authorized to use, with the benefits that bring using publicly trusted certificates. Enforcing EKU separation will imply having two or more different CAs in a single AD, which is not that easy to manage, and forces also the acquisition of multiple HSM or expensive network HSM.

As an additional comment, and considering this certain trend to "over regulation", and clarifying that I perfectly understand the need to control commercial CAs, I must say that for me personally new rules like the enforcement of CT on a name constrained CA doesn't bring a clear value in terms of risk management, but just adding complexity for a CA which is only entitled to issue certificates in a very controlled scope.

But these comments are just my humble opinion... we'll just adapt to whatever is the result of this discussion.

BR/Pedro

[Ryan Sleevi]

On Sun, Apr 29, 2018 at 10:12 AM, pfuentes69--- via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> With all my respects to the experts involved in this discussion, my
> statement is based in risk management, and I just think there's maybe no
> need to over-regulate name-constrained CAs, as this technique is already
> reducing the risks that those new rules intend to control.
>
> Name Constraints, as used in practice, define a name span of "only
> allowed" DNS and Organization names, so it's not actually a blacklist, but
> an exclusive whitelist.

Unfortunately, this is not a correct understanding of nameConstraints. As
described in RFC 5280, Section 4.2.1.10 (
https://tools.ietf.org/html/rfc5280#section-4.2.1.10 ), and as further
expanded within the processing model, nameConstraints only apply to the
name types specifically enumerated within the nameConstraints extension -
that is, they don't apply to other name types that are specified. This is
why, for example, the CA/Browser Forum requires that the CA explicitly
enumerate the iPAddress, dNSName, and directoryName name constraints, to
ensure that those types are all constrained. However, the introduction of
any other name types is further problematic.

> We must also consider that even if not disclosed in the CCADB, when we
> "suffer" a Webtrust audit we are screened on the effective usage of name
> constraints in all issued CA Certificates, so an auditor won't accept a CA
> as "out of scope of the BR audit" if it's merely whitelisting certain names
> or merely blacklisting certain other names... but effectively limiting the
> activity of a CA to a closed set of names, which BTW are vetted prior to
> execute the CA ceremony.
>

This is not consistent with what we see in practice, so I'm not sure this
is a reasonable conclusion to pin all our hopes on.

> Therefore, my statement is made considering the corporate customers that
> want a root signing service for their own CA, sometimes linked to an Active
> Directory and aiming to fulfill the needs of the company for personal and
> server certificates in the domains they own or are authorized to use, with
> the benefits that bring using publicly trusted certificates. Enforcing EKU
> separation will imply having two or more different CAs in a single AD,
> which is not that easy to manage, and forces also the acquisition of
> multiple HSM or expensive network HSM.
>

Can you further expand on this? This was the piece of information that was
previously missing, and remains missing. What is your envisioned use case
for this, in which multiple EKUs benefit from public trust?

> As an additional comment, and considering this certain trend to "over
> regulation", and clarifying that I perfectly understand the need to control
> commercial CAs, I must say that for me personally new rules like the
> enforcement of CT on a name constrained CA doesn't bring a clear value in
> terms of risk management, but just adding complexity for a CA which is only
> entitled to issue certificates in a very controlled scope.
>

Of course, while limited in scope, there are still an ample number of ways
such a CA could misissue - with the most obvious and alluring of these
being related to key sizes.

[Ryan Sleevi]

On Wed, Apr 25, 2018 at 1:03 PM, Wayne Thayer <wth...@mozilla.com> wrote:

> On Tue, Apr 24, 2018 at 9:24 AM, Ryan Sleevi <ry...@sleevi.com> wrote:
>
>> I'm not sure I underestand the use case. I'm hoping that they can clarify
>> more.
>>
>> Pedro - can you explain more about why this is important?
>
> That is, it would seem valuable as part of the technical constraint
>> exercise to ensure the EKUs are restsricted. This is particularly true due
>> to how nameConstraints work - they are blacklists (effectively), rather
>> than whitelists, which means that combined with EKUs, they can be used for
>> unconstrained purposes.
>>
>> Similar to the discussions regarding nameConstraints and name types, this
>> has the effect of discouraging the introduction of new EKUs, as such
>> intermediates would be unconstrained for these potential new and novel EKU
>> use cases.
>>
>> Ryan - can you explain this concern in more detail? If, for instance, the
> srvName type was added for TLS certificates, new intermediates would be
> required to constrain that name type due to the "fail open" nature of name
> constraints. If a single intermediate contained both the serverAuth and
> emailProtection EKUs, how does that make the situation worse? Is it just
> that now all of the S/MIME certificates issued under the intermediate must
> also expire or be replaced so that the old intermediate (without a
> constraint on srvName) can be revoked?
>

You're absolutely correct that if an intermediate certificate contains
serverAuth and emailProtection EKUs, then we are bounded in the types of
certificates it issues. It is only in the situation where it lacks an EKU,
or where it's granted the anyExtendedKeyusage EKU, that we're in a
situation where we're failing "open".

My understanding of the proposal to "make an exception" for nameConstrained
CAs was to allow any of these - that is, a combination of explicit EKUs,
lacking an EKU, and an anyEKU. The consequence of this would be that the
introduction of srvName for TLS, in the case of (lacking an EKU, any EKU),
would mean that such an intermediate is unconstrained for TLS issuance -
even if it was only 'intended' for something such as S/MIME and smart-card
auth.

If the proposal is to allow multiple (explicit) EKUs on an intermediate,
when the intermediate also has constraints appropriate for each of the
enumerated EKUs, then I think we're in a better place, although we should
understand the motivation more :)

[Wayne Thayer]

This proposal wouldn't change the current requirement for technically
constrained intermediates:

For a certificate to be considered technically constrained, the certificate
MUST include an Extended Key Usage (EKU) extension specifying all extended
key usages that the subordinate CA is authorized to issue certificates for.
The anyExtendedKeyUsage KeyPurposeId MUST NOT appear within this extension.

[pfuen...@gmail.com]

Hi Ryan,
thanks for your enlightening feedback to my poor comments... let me try to add some more here.

El lunes, 30 de abril de 2018, 17:22:38 (UTC+2), Ryan Sleevi escribió:
> On Sun, Apr 29, 2018 at 10:12 AM, pfuentes69--- via dev-security-policy <
> dev-secur...@lists.mozilla.org> wrote:
>
> > With all my respects to the experts involved in this discussion, my
> > statement is based in risk management, and I just think there's maybe no
> > need to over-regulate name-constrained CAs, as this technique is already
> > reducing the risks that those new rules intend to control.
> >
> > Name Constraints, as used in practice, define a name span of "only
> > allowed" DNS and Organization names, so it's not actually a blacklist, but
> > an exclusive whitelist.
>
>
> Unfortunately, this is not a correct understanding of nameConstraints. As
> described in RFC 5280, Section 4.2.1.10 (
> https://tools.ietf.org/html/rfc5280#section-4.2.1.10 ), and as further
> expanded within the processing model, nameConstraints only apply to the
> name types specifically enumerated within the nameConstraints extension -
> that is, they don't apply to other name types that are specified. This is
> why, for example, the CA/Browser Forum requires that the CA explicitly
> enumerate the iPAddress, dNSName, and directoryName name constraints, to
> ensure that those types are all constrained. However, the introduction of
> any other name types is further problematic.
>

Probably it's a language issue, but I would say that that was what I said, or at least what I intended to say...

Another point is that the real-life implementations are tricky sometimes... For example:
- By default MS CA adds empty entries to the permitted name list for the types of names not specified, so for example if you don't include the IP addresses constraints in the capolicy.inf file, then it will add automatically a constraint to disallow IP addresses, unfortunately in a non-very standard way that some certificate parsers don't like much (but effective when issuing certificates from a MS CA).
- Same applies to the specification for name constraints in email addresses, MS specified this in the documentation in a way that is not fully in line of the RFC, and that caused trouble in the past
- AFAIK Apple still doesn't like the name constraints extension to be critical, as it brings an untrusted certificate error

So I see your concern on name constraints not being used properly... as actually aren't that easy to implement.

>
> > We must also consider that even if not disclosed in the CCADB, when we
> > "suffer" a Webtrust audit we are screened on the effective usage of name
> > constraints in all issued CA Certificates, so an auditor won't accept a CA
> > as "out of scope of the BR audit" if it's merely whitelisting certain names
> > or merely blacklisting certain other names... but effectively limiting the
> > activity of a CA to a closed set of names, which BTW are vetted prior to
> > execute the CA ceremony.
> >
>
> This is not consistent with what we see in practice, so I'm not sure this
> is a reasonable conclusion to pin all our hopes on.
>

Well, that's another problem. At least we're used to play according to the rules, but also to be checked to do so. But you speak with a broader view on this, so I understand your point.

>
> > Therefore, my statement is made considering the corporate customers that
> > want a root signing service for their own CA, sometimes linked to an Active
> > Directory and aiming to fulfill the needs of the company for personal and
> > server certificates in the domains they own or are authorized to use, with
> > the benefits that bring using publicly trusted certificates. Enforcing EKU
> > separation will imply having two or more different CAs in a single AD,
> > which is not that easy to manage, and forces also the acquisition of
> > multiple HSM or expensive network HSM.
> >
>
> Can you further expand on this? This was the piece of information that was
> previously missing, and remains missing. What is your envisioned use case
> for this, in which multiple EKUs benefit from public trust?
>

I'm just stating a customer demand that I've seen several times already: a company that wants an internal CA (typically a MS CA linked to the Active Directory) to issue certificates that are valid for several uses, being one secure email (i.e. outgoing signed messages easy to verify). These same customers typically also want to use trusted certs for web or other servers using the serverAuth EKU.

>
> > As an additional comment, and considering this certain trend to "over
> > regulation", and clarifying that I perfectly understand the need to control
> > commercial CAs, I must say that for me personally new rules like the
> > enforcement of CT on a name constrained CA doesn't bring a clear value in
> > terms of risk management, but just adding complexity for a CA which is only
> > entitled to issue certificates in a very controlled scope.
> >
>
> Of course, while limited in scope, there are still an ample number of ways
> such a CA could misissue - with the most obvious and alluring of these
> being related to key sizes.

Maybe I'm too pragmatic, but from a risk management perspective, I don't see a constrained CA issuing a poor certificate harming the whole CA/Browser community, so I would even accept that risk.

Anyway, as a conclusion, I see your point about this maybe being difficult to manage in the real world, so I guess my request to consider the exception for name constrained CAs is not as straightforward as it's in my head.

Cheers!

[Jakob Bohm]

However maybe an additional (clarifying or new) requirement set:

To be considered as a name constrained SubCA, the SubCA certificate must
satisfy all of the following:

1. Specify a specific non-empty list or permitted EKUs, which does not
include the value anyExtendedKeyUsage.

2. Specify name constraints (whitelist-based) for all the name types
that can be used with the specified permitted EKUs. Any EV-capable
such SubCA must also specify name constraints for the directory name
type.

3. Each name constraint must permit only names for which the holder of
the name constrained CA has been fully vetted as ultimately
authoritative. For example, any DNS names must correspond to domains
registered to the holder for a registration period completely
overlapping the CA cert validity period. Any Distinguished name must
correspond to the verified real world identity of the holder (for
example C=US, O=Google Inc would be a permitted dirname subtree
constraint for a subCA issued to the US headquarters of Google Inc.
The validation must be done to standards above and beyond the
standards required for end entity certificates of the types that the
SubCA can issue.

[Wayne Thayer]

Jakob,

On Tue, May 1, 2018 at 1:14 PM, Jakob Bohm via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote

>

> However maybe an additional (clarifying or new) requirement set:
>

> I think the existing language in section 5.3.1 covers all of this. If not,
can you point out the gaps so that I can open a new issue?

To be considered as a name constrained SubCA, the SubCA certificate must
> satisfy all of the following:
>
> 1. Specify a specific non-empty list or permitted EKUs, which does not
> include the value anyExtendedKeyUsage.
>
> 2. Specify name constraints (whitelist-based) for all the name types
> that can be used with the specified permitted EKUs. Any EV-capable
> such SubCA must also specify name constraints for the directory name
> type.
>
> 3. Each name constraint must permit only names for which the holder of
> the name constrained CA has been fully vetted as ultimately
> authoritative. For example, any DNS names must correspond to domains
> registered to the holder for a registration period completely
> overlapping the CA cert validity period. Any Distinguished name must
> correspond to the verified real world identity of the holder (for
> example C=US, O=Google Inc would be a permitted dirname subtree
> constraint for a subCA issued to the US headquarters of Google Inc.
> The validation must be done to standards above and beyond the
> standards required for end entity certific

> <https://maps.google.com/?q=andards+required+for+end+entity+certific&entry=gmail&source=g>ates

[Wayne Thayer]

Unless there is further discussion, I will consider this issue closed with
the following change to section 5.3, meaning that it applies to both
unconstrained and technically constrained intermediates:

Subordinate CA certificates created after January 1, 2019:

* 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.

- Wayne