Policy 2.7 Proposal: Require EKUs in End-Entity Certificates

[Wayne Thayer]

The BRs require EKUs in leaf TLS certs, but there is no equivalent
requirement for S/MIME certificates. This leads to confusion such as [1] in
which certificates that are not intended for TLS or S/MIME fall within the
scope of our policies.

Simply requiring EKUs in S/MIME certificates won't solve the problem unless
we are willing to exempt certificates without an EKU from our policies, and
doing that would create a rather obvious loophole for issuing S/MIME
certificates that don't adhere to our policies.

The proposed solution is to require EKUs in all certificates that chain up
to roots in our program, starting on some future effective date (e.g. April
1, 2020). This has the potential to cause some compatibility problems that
would be difficult to measure and assess. Before drafting language for this
proposal, I would like to gauge everyone's support for this proposal.

Alternately, we could easily argue that section 1.1 of our existing policy
already makes it clear that CAs must include EKUs other than
id-kp-serverAuth and id-kp-emailProtection in certificates that they wish
to remain out of scope for our policies.

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

I will greatly appreciate everyone's input on this topic.

- Wayne

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1523221

[Brian Smith]

Wayne Thayer via dev-security-policy <dev-secur...@lists.mozilla.org>
wrote:

> This leads to confusion such as [1] in
> which certificates that are not intended for TLS or S/MIME fall within the
> scope of our policies.
>

I disagree that there is any confusion. The policy is clear, as noted in
https://bugzilla.mozilla.org/show_bug.cgi?id=1523221#c3.

Simply requiring EKUs in S/MIME certificates won't solve the problem unless
> we are willing to exempt certificates without an EKU from our policies, and
> doing that would create a rather obvious loophole for issuing S/MIME
> certificates that don't adhere to our policies.
>

I agree that a requirement to add an EKU to certificates does not solve the
problem, because the problem that software (Mozilla's and others')
interprets the lack of an EKU extension as meaning "there is no restriction
on the EKU," which is the correct interpretation.

> The proposed solution is to require EKUs in all certificates that chain up
> to roots in our program, starting on some future effective date (e.g. April
> 1, 2020).

Here when you say "require EKUs," you mean that you are proposing that
software that uses Mozilla's trust store must be modified to reject
end-entity certificates that do not contain the EKU extension, if the
certificate chains up to the roots in Mozilla's program, right? If so, how
would one implement the "chain[s] up to roots in our program" check? What's
the algorithm? Is that actually well-defined?

> Alternately, we could easily argue that section 1.1 of our existing policy
> already makes it clear that CAs must include EKUs other than
> id-kp-serverAuth and id-kp-emailProtection in certificates that they wish
> to remain out of scope for our policies.
>

I agree the requirements are already clear. The problem is not the clarity
of the requirements. Anybody can define a new EKU because EKUs are listed
in the certificate by OIDs, and anybody can make up an EKU. A standard
isn't required for a new OID. Further, not agreeing on a specific EKU OID
for a particular kind of usage is poor practice, and we should discourage
that poor practice.

Cheers,
Brian
--
https://briansmith.org/

[Wayne Thayer]

Brian,

I think we are in agreement that this isn't a desirable addition to our
policy.

On Mon, Apr 1, 2019 at 5:36 PM Brian Smith via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> Wayne Thayer via dev-security-policy <
> dev-secur...@lists.mozilla.org>
> wrote:
>
> Here when you say "require EKUs," you mean that you are proposing that
> software that uses Mozilla's trust store must be modified to reject
> end-entity certificates that do not contain the EKU extension, if the
> certificate chains up to the roots in Mozilla's program, right?

That would be a logical goal, but I was only contemplating a policy
requirement.

If so, how
> would one implement the "chain[s] up to roots in our program" check? What's
> the algorithm? Is that actually well-defined?
>
>

My starting proposal would be to reject all EE certs issued after a certain
future date that don't include EKU(s), or that assert anyEKU. If your point
is that it's not so simple and that this will break things, I suspect that
you are correct.

- Wayne

[Doug Beattie]

Wayne,

The Microsoft policy already requires that CAs include EKUs in all EE
certificates that chain up to roots in their program. See 4.A.18 in
http://aka.ms/RootCert

Effective February 1, 2017, all end-entity certificates must contain the EKU
for the purpose that the CA issued the certificate to the customer, and the
end-entity certificate may not use "any EKU."

I wonder if there roots in the Mozilla program that are not in the MS
program that "need" to be issued without EKUs? I'm not sure who can answer
that question, but if there are objections by CAs then this is the time they
should raise them.

Doug

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

[Brian Smith]

Wayne Thayer <wth...@mozilla.com> wrote:

> On Mon, Apr 1, 2019 at 5:36 PM Brian Smith via dev-security-policy <
> dev-secur...@lists.mozilla.org> wrote:
>
>> Here when you say "require EKUs," you mean that you are proposing that
>> software that uses Mozilla's trust store must be modified to reject
>> end-entity certificates that do not contain the EKU extension, if the
>> certificate chains up to the roots in Mozilla's program, right?
>
>
> That would be a logical goal, but I was only contemplating a policy
> requirement.
>

OK, let's say the policy were to change to require an EKU in every
end-entity certificate. Then, would the policy also require that existing
unexpired certificates that lack an EKU be revoked? Would the issuance of a
new certificate without an EKU be considered a policy violation that would
put the CA at risk of removal?

The thing I want to avoid is saying "It is OK for the CA to issue an
end-entity certificate without an EKU and if there is no EKU we will
consider it out of scope of the program." In particular, I don't want to
put software that (correctly) implements the "no EKU extension implies all
usages are acceptable" at risk.

>
> If so, how
>> would one implement the "chain[s] up to roots in our program" check?
>> What's
>> the algorithm? Is that actually well-defined?
>>
>>
> My starting proposal would be to reject all EE certs issued after a
> certain future date that don't include EKU(s), or that assert anyEKU. If
> your point is that it's not so simple and that this will break things, I
> suspect that you are correct.
>

The part that seems difficult to implement is the differentiation of a
certificate that chains up to a root in Mozilla's program from one that
doesn't. I don't think there is a good way to determine, given the
information that the certificate verifier has, whether a certificate chains
up to a root in Mozilla's program or not, so to be safe software has to
apply the same rules to regardless of whether the certificate appears to
chain up to a root in Mozilla's program or not.

[Wayne Thayer]

On Wed, Apr 3, 2019 at 6:30 PM Brian Smith <br...@briansmith.org> wrote:

> Wayne Thayer <wth...@mozilla.com> wrote:
>
>> On Mon, Apr 1, 2019 at 5:36 PM Brian Smith via dev-security-policy <
>> dev-secur...@lists.mozilla.org> wrote:
>>
>>> Here when you say "require EKUs," you mean that you are proposing that
>>> software that uses Mozilla's trust store must be modified to reject
>>> end-entity certificates that do not contain the EKU extension, if the
>>> certificate chains up to the roots in Mozilla's program, right?
>>
>>
>> That would be a logical goal, but I was only contemplating a policy
>> requirement.
>>
>
> OK, let's say the policy were to change to require an EKU in every
> end-entity certificate. Then, would the policy also require that existing
> unexpired certificates that lack an EKU be revoked?
>

No, there would be an effective date.

Would the issuance of a new certificate without an EKU be considered a
> policy violation that would put the CA at risk of removal?
>
>

Yes.

The thing I want to avoid is saying "It is OK for the CA to issue an
> end-entity certificate without an EKU and if there is no EKU we will
> consider it out of scope of the program." In particular, I don't want to
> put software that (correctly) implements the "no EKU extension implies all
> usages are acceptable" at risk.
>
>

Agreed. I am leaning toward dropping this proposal altogether.

[Tadahiko Ito]

On Tuesday, April 2, 2019 at 9:36:06 AM UTC+9, Brian Smith wrote:

> I agree the requirements are already clear. The problem is not the clarity
> of the requirements. Anybody can define a new EKU because EKUs are listed
> in the certificate by OIDs, and anybody can make up an EKU. A standard
> isn't required for a new OID. Further, not agreeing on a specific EKU OID
> for a particular kind of usage is poor practice, and we should discourage
> that poor practice.
>

It is good that anyone can make OID, so we do not need to violate policy.

However, I have following concerns with increasing private OIDs in the world.
-I think that OID should be CA’s private OID or public OID. because, in the case of a CA is going to out of business, and that business was cared by another CA, we would not want those two CA using same OID for different usage.
-In the other hand, CA’s private OIDs will reduce interoperability, which seems to be problematic,
-web browser might just ignore private OIDs, but I am not sure other certificate verification applications,
which is used for certificate of that private EKU OID.

over all, I think we should have some kind of public OIDs, at least for widely use purpose.

I believe if it were used for internet, we can write Internet-Draft, and ask OIDs on RFC3280 EKU repo.
#I am planing to try that.


Tadahiko Ito

[Jakob Bohm]

The common way to create an OID is to get an OID assigned to your (CA)
business, either through a national standards organization or by getting
an "enterprise ID" from IANA.

Then append self-chosen suffixes to subdivide your new (near infinite)
OID name space. For example, if your national standards organization
assigned your CA the OID "9.99.999.9999" (not actually a valid OID btw),
you could subdivide like this (fun example).

9.99.999.9999.1 - Certificate policies
9.99.999.9999.1.1 - Your test certificates policy
9.99.999.9999.1.1.2019.3.12 - March 12, 2019 version of that policy
9.99.999.9999.1.2 - Your EV policy
9.99.999.9999.2 - EKUs
9.99.999.9999.2.1 - CA internal Database backup signatures
9.99.999.9999.2.2 - login certificates for the secure room door lock
9.99.999.9999.2.3 - Gateway certificates for custom protocol X
9.99.999.9999.3 - Custom DN elements
9.99.999.9999.3.1 - Paygrade
9.99.999.9999.4 - Certificate/CMS/CRL/OCSP extensions
9.99.999.9999.4.1 - Date and location of photo ID validation
9.99.999.9999.5 - Algorithms
9.99.999.9999.5.1 - Caesar encryption.
9.99.999.9999.5.2 - CRC8 hash
9.99.999.9999.99999 - East company division
9.99.999.9999.99999.999999.9999999 - This is getting silly.

Etc.

A different CA would have (by the hierarchical nature of the OID system)
a different assigned OID such as 9.88.999.9999 thus not overlapping.

Thus no risk of conflicting uses unless someone breaks the basic OID
rules. The actual risk (as illustrated by EV) is getting too many
different OIDs for the same thing.



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

[Ryan Sleevi]

On Tue, Apr 16, 2019 at 12:41 PM Jakob Bohm via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> On 16/04/2019 08:56, Tadahiko Ito wrote:

I don't believe there was any confusion about that. Indeed, the message
you're replying to already acknowledges that CAs can do exactly that.

The only concern, it seems, which this message does not address at all, was
about the desire to have a common OID used across multiple CAs for
particular use cases, so that relying party software can trust certificates
from multiple (different) CAs and validate the end-entity certificates as
appropriate for that OID.

I think the substance of the message being replied to was missed, and
hopefully that clarification helps.

[Wayne Thayer]

My conclusion from this discussion is that we should not add an explicit
requirement for EKUs in end-entity certificates. I've closed the issue.

- Wayne

On Tue, Apr 16, 2019 at 9:56 AM Ryan Sleevi via dev-security-policy <

dev-secur...@lists.mozilla.org> wrote:

> On Tue, Apr 16, 2019 at 12:41 PM Jakob Bohm via dev-security-policy <
> dev-secur...@lists.mozilla.org> wrote:
>
> > On 16/04/2019 08:56, Tadahiko Ito wrote:

[Brian Smith]

Wayne Thayer via dev-security-policy <dev-secur...@lists.mozilla.org>
wrote:

> My conclusion from this discussion is that we should not add an explicit
> requirement for EKUs in end-entity certificates. I've closed the issue.
>

What will happen to all the certificates without an EKU that currently
exist, which don't conform to the program requirements?

For what it's worth, I don't object to a requirement for having an explicit
EKU in certificates covered by the program. Like I said, I think every
certificate that is issued should be issued with a clear understanding of
what applications it will be used for, and having an EKU extension does
achieve that.

The thing I am attempting to avoid is the implication that a missing EKU
implies a certificate is not subject to the program's requirements.

Cheers,
Brian

[Ryan Hurst]

For what it is worth I agree with Brian.

I would go a bit further and say certificates need to be issued for explicit usages anything else produces potentially unknown behaviors.

What's most important though is that any certificate that is trusted as a result of membership in the Mozilla root program that can technically be used for SSL on the public web is subject to the program requirements intent or not.

It seems since MSFT already requires leaves to have an EKU it wouldn't be breaking to apply the same rule in Mozilla's program.

Ryan

[Wayne Thayer]

On Wed, Apr 17, 2019 at 5:05 PM Ryan Hurst via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> For what it is worth I agree with Brian.
>
> I would go a bit further and say certificates need to be issued for
> explicit usages anything else produces potentially unknown behaviors.
>
> What's most important though is that any certificate that is trusted as a
> result of membership in the Mozilla root program that can technically be
> used for SSL on the public web is subject to the program requirements
> intent or not.
>
> It seems since MSFT already requires leaves to have an EKU it wouldn't be
> breaking to apply the same rule in Mozilla's program.
>
>

Okay, then I propose adding the following to section 5.2 "Forbidden and
Required Practices":

Effective for certificates issued on or after April 1, 2020, end-entity
certificates MUST include an EKU extension containing KeyPurposeId(s)
describing the intended usage(s) of the certificate, and the EKU extension
MUST NOT contain the KeyPurposeId anyExtendedKeyUsage.

This does not imply that there will be technical enforcement, but also
doesn't rule it out.

I will appreciate everyone's feedback on this proposal.

Ryan
> On Wednesday, April 17, 2019 at 12:27:49 PM UTC-7, Brian Smith wrote:

> > Wayne Thayer via dev-security-policy <
> dev-secur...@lists.mozilla.org>
> > wrote:
> >
> > > My conclusion from this discussion is that we should not add an
> explicit
> > > requirement for EKUs in end-entity certificates. I've closed the issue.
> > >
> >
> > What will happen to all the certificates without an EKU that currently
> > exist, which don't conform to the program requirements?
> >
>

Such certificates are misissued under our current policy. Nothing would
change.

> For what it's worth, I don't object to a requirement for having an
> explicit
> > EKU in certificates covered by the program. Like I said, I think every
> > certificate that is issued should be issued with a clear understanding of
> > what applications it will be used for, and having an EKU extension does
> > achieve that.
> >
> > The thing I am attempting to avoid is the implication that a missing EKU
> > implies a certificate is not subject to the program's requirements.
> >
>

Yes, that's the misunderstanding this issue is attempting to fix.

> Cheers,
> > Brian
>

[Matt Palmer]

On Fri, Apr 19, 2019 at 01:22:59PM -0700, Wayne Thayer via dev-security-policy wrote:
> Okay, then I propose adding the following to section 5.2 "Forbidden and
> Required Practices":
>
> Effective for certificates issued on or after April 1, 2020, end-entity
> certificates MUST include an EKU extension containing KeyPurposeId(s)
> describing the intended usage(s) of the certificate, and the EKU extension
> MUST NOT contain the KeyPurposeId anyExtendedKeyUsage.
>
> This does not imply that there will be technical enforcement, but also
> doesn't rule it out.
>
> I will appreciate everyone's feedback on this proposal.

If I may pick the absolute smallest of nits, is it "better" if the
restriction be on certificate notBefore, rather than "issued on"? Whilst
that leaves certificates open to backdating, it does make it easier to
identify misissuance. Otherwise there could be arguments made that the
certificate was *actually* issued before the effective date, even though
there is no evidence that that is the case.

- Matt

[Wayne Thayer]

> Thanks Matt, I can see how that change makes it easier to check for
compliance.

I've added my proposal, updated per Matt's suggestion, to the 2.7 branch:

https://github.com/mozilla/pkipolicy/commit/842c9bd53e43904b160e79cb199018252fb60834

Unless there are further comments, I'll consider this issue resolved.

- Wayne

[Dimitris Zacharopoulos]

Wayne,

I support this update but I am not sure if this is somehow linked with
the scope of the Mozilla Policy. Does this change mean that after April
1, 2020, any Certificate that does not have an EKU is out of Mozilla
Policy scope or not? I think the GRCA discussion around special-purpose
certificates (I think they were meant for document signing) that do not
contain an EKU (nor an emailAddress in the SAN extension or the CN
subjectDN field), are currently considered in scope.

If this change intends to bring these types of certificates out of scope
after April 1, 2020, we must make this clear and probably also update
section 1.1.


Dimitris.

>
> - Wayne

[Matt Palmer]

On Wed, Apr 24, 2019 at 09:13:31AM +0300, Dimitris Zacharopoulos via dev-security-policy wrote:
> I support this update but I am not sure if this is somehow linked with the
> scope of the Mozilla Policy. Does this change mean that after April 1, 2020,
> any Certificate that does not have an EKU is out of Mozilla Policy scope or
> not?

Given that the change doesn't touch section 1.1, it's reasonable to believe
that the scope of the policy is not changing.

> If this change intends to bring these types of certificates out of scope
> after April 1, 2020, we must make this clear and probably also update
> section 1.1.

My reading of the policy, as amended by this proposal, as well as my
understanding of past discussions in this group, is that certificates
without an EKU are in scope now, and they will continue to be in scope if
this amendment is adopted. The only change is that end-entity certificates
without an EKU will be considered misissued if the certificate's notBefore
is on or after April 1, 2020.

If you feel that the policy, as amended, does not make this state of affairs
clear, I'm sure Wayne would welcome suggestions for improvement.

- Matt

[Dimitris Zacharopoulos]

I think your explanation clarifies the intent and the policy language
make sense. I wasn't 100% sure if the intent was to narrow the scope or
not.


Thanks,
Dimitris.

> - Matt

[hor...@gmail.com]

Wayne Thayer於 2019年3月30日星期六 UTC+8上午4時48分27秒寫道：

GPKI(Taiwan) will follow Mozilla policy to add EKU to EE certificates
However, the influence range of implementation is very large.
We need to define our own Document Signing EKU and data encryption EKU, and coordinate all subordinate Cas(Five CAs) and application system’s owners(more than 2,000 application systems).
It needs a whole year to implement this. Therefore, after multiple evaluations, it is decided to officially add the EKU to the user certificate on January 1, 2021.
It is difficult for us to complete ahead of April 2020.
Can we get more buffer?

[Wayne Thayer]

On Tue, Jul 9, 2019 at 2:12 AM horn917--- via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> Wayne Thayer於 2019年3月30日星期六 UTC+8上午4時48分27秒寫道：

> GPKI(Taiwan) will follow Mozilla policy to add EKU to EE certificates
> However, the influence range of implementation is very large.
> We need to define our own Document Signing EKU and data encryption EKU,
> and coordinate all subordinate Cas(Five CAs) and application system’s
> owners(more than 2,000 application systems).
> It needs a whole year to implement this. Therefore, after multiple
> evaluations, it is decided to officially add the EKU to the user
> certificate on January 1, 2021.
> It is difficult for us to complete ahead of April 2020.
> Can we get more buffer?
>
>

I had expected to have this policy update completed sooner when I proposed
April 2020 as the date for requiring EKUs in end-entity certificates. Given
that, I think it's reasonable to push the date back to July 2020, but not
to January 2021. 2021 seems particularly unreasonable in light of the
Microsoft requirement [1] that went into effect in January 2017 and appears
to apply to GPKI.

Will any other CAs find it impossible to meet this requirement for
certificates issued after June 2020? Also, are there any concerns with this
applying to certificates issued from technically constrained intermediate
CA certificates? As-proposed, this applies to those certificates (and it
appears to me that Microsoft's policy does as well).

- Wayne

[1]
https://docs.microsoft.com/en-us/security/trusted-root/program-requirements#4-program-technical-requirements

[Jeremy Rowley]

I'm surprised any CA has heartburn over the EKU changes. Microsoft has required them in end entity certificates for quite some time. From the MS policy: "Effective February 1, 2017, all end-entity certificates must contain the EKU for the purpose that the CA issued the certificate to the customer, and the end-entity certificate may not use “any EKU.”" There's a chance that the CA is not in Microsoft, but I thought Mozilla usually had fewer CAs than Microsoft included.

-----Original Message-----
From: dev-security-policy <dev-security-...@lists.mozilla.org> On Behalf Of Wayne Thayer via dev-security-policy
Sent: Wednesday, October 2, 2019 6:05 PM
To: hor...@gmail.com
Cc: mozilla-dev-security-policy <mozilla-dev-s...@lists.mozilla.org>
Subject: Re: Policy 2.7 Proposal: Require EKUs in End-Entity Certificates

On Tue, Jul 9, 2019 at 2:12 AM horn917--- via dev-security-policy < dev-secur...@lists.mozilla.org> wrote:

> Wayne Thayer於 2019年3月30日星期六 UTC+8上午4時48分27秒寫道：

> GPKI(Taiwan) will follow Mozilla policy to add EKU to EE certificates
> However, the influence range of implementation is very large.
> We need to define our own Document Signing EKU and data encryption
> EKU, and coordinate all subordinate Cas(Five CAs) and application
> system’s owners(more than 2,000 application systems).
> It needs a whole year to implement this. Therefore, after multiple
> evaluations, it is decided to officially add the EKU to the user
> certificate on January 1, 2021.
> It is difficult for us to complete ahead of April 2020.
> Can we get more buffer?
>
>
I had expected to have this policy update completed sooner when I proposed April 2020 as the date for requiring EKUs in end-entity certificates. Given that, I think it's reasonable to push the date back to July 2020, but not to January 2021. 2021 seems particularly unreasonable in light of the Microsoft requirement [1] that went into effect in January 2017 and appears to apply to GPKI.

Will any other CAs find it impossible to meet this requirement for certificates issued after June 2020? Also, are there any concerns with this applying to certificates issued from technically constrained intermediate CA certificates? As-proposed, this applies to those certificates (and it appears to me that Microsoft's policy does as well).

- Wayne

[1]
https://docs.microsoft.com/en-us/security/trusted-root/program-requirements#4-program-technical-requirements

[Wayne Thayer]

I've gone ahead and moved the effective date of this policy back to July 1,
2020:
https://github.com/mozilla/pkipolicy/commit/7a879fe371844d265c484a8f0ce40fd255967c13

On Wed, Oct 2, 2019 at 6:04 PM Jeremy Rowley <jeremy...@digicert.com>
wrote:

> I'm surprised any CA has heartburn over the EKU changes. Microsoft has
> required them in end entity certificates for quite some time. From the MS
> policy: "Effective February 1, 2017, all end-entity certificates must
> contain the EKU for the purpose that the CA issued the certificate to the
> customer, and the end-entity certificate may not use “any EKU.”" There's a
> chance that the CA is not in Microsoft, but I thought Mozilla usually had
> fewer CAs than Microsoft included.
>
> -----Original Message-----
> From: dev-security-policy <dev-security-...@lists.mozilla.org>
> On Behalf Of Wayne Thayer via dev-security-policy
> Sent: Wednesday, October 2, 2019 6:05 PM
> To: hor...@gmail.com
> Cc: mozilla-dev-security-policy <
> mozilla-dev-s...@lists.mozilla.org>
> Subject: Re: Policy 2.7 Proposal: Require EKUs in End-Entity Certificates
>
> On Tue, Jul 9, 2019 at 2:12 AM horn917--- via dev-security-policy <
> dev-secur...@lists.mozilla.org> wrote:
>
> > Wayne Thayer於 2019年3月30日星期六 UTC+8上午4時48分27秒寫道：