Subject: [Spasm] draft-housley-spasm-eku-constraints-01.txt

From: Russ Housley <[email-masked]>
Date: Wed, 18 May 2016 13:22:57 -0400

There have been many changes discussed over the past few days.  There have not been any comments for a few hours, so I have collected them into -01.

> Name:		draft-housley-spasm-eku-constraints
> Revision:	01
> Title:		Extended Key Usage Constraints
> Document date:	2016-05-17
> Group:		Individual Submission
> Pages:		8
> URL:            https://www.ietf.org/internet-drafts/draft-housley-spasm-eku-constraints-01.txt
> Status:         https://datatracker.ietf.org/doc/draft-housley-spasm-eku-constraints/
> Htmlized:       https://tools.ietf.org/html/draft-housley-spasm-eku-constraints-01
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-housley-spasm-eku-constraints-01
> 
> Abstract:
>   This document specifies the extended key usage constraints
>   certificate extension, which is used to place restrictions on the key
>   purpose identifiers that are authorized to appear in the end-entity
>   certificate in a certification path.  Restrictions apply to the
>   extended key usage certificate extension, which is described in
>   RFC 5280.

As always, review and comments are most welcome.

Russ

---

From: Stefan Santesson <[email-masked]>
Date: Wed, 18 May 2016 23:10:54 +0200

Russ,

Reading 01 my reflections are:

1) I don’t like that this extension MUST be critical. It’s a deployment killer. Who can include it before all validation engines support it, and who will bother to support it when no one includes it?
2) This is too complex for my taste.

I know that everything in the draft makes sense, but it may just be a bit too complex to get implemented and used correctly.
Have anyone made a study on where this is needed, and in what situations?

I know from my Microsoft days that Microsoft had an internal processing of EKU in CA certs in order to limit which certs that could be used under which root. Mainly for constraining code signing usage.
Microsoft attempted to solve the same type of issue at one stage by introducing application policies with exclude and include logic. It never got used.

Perhaps we just need an extension that has 1 bit in it. If set to 1 it means that EKUs in this CA certificate are constraining the allowed EKU:s in the path.

I actually think that would do what I suspect is needed and would cause the least impact on existing path validation engines.

/Stefan

On 18/05/16 19:22, "Spasm on behalf of Russ Housley" <[email-masked] on behalf of [email-masked]> wrote:

>_______________________________________________
>Spasm mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/spasm

---

From: Russ Housley <[email-masked]>
Date: Thu, 19 May 2016 08:34:52 -0400

In an off-list discussion, Santosh has suggested that Section 3.5 needs a additional check to deal with end-entity certificates that do not include an EKU extension.

He has suggested this text:

   (i)  If the EKU extension is absent from the end-entity certificate
        then confirm that the permitted_key_purpose_ids state variable
        is the universal set and the excluded_key_purpose_ids state
        variable is the empty set.  Otherwise, return a failure indication
       and an appropriate reason.

Thoughts?

Russ

---

From: Russ Housley <[email-masked]>
Date: Mon, 23 May 2016 13:29:22 -0400

> 1) I don’t like that this extension MUST be critical. It’s a deployment killer. Who can include it before all validation engines support it, and who will bother to support it when no one includes i…

We have had this same debate with other must-be-critical extensions.  RFC 5280 has set the precedent on criticality for an extension in a CA certificate that impose restrictions on things that can appear in subsequent certificates in the path:

  4.2.1.10.  Name Constraints

    Conforming CAs MUST mark this extension as critical …

  4.2.1.11.  Policy Constraints

     Conforming CAs MUST mark this extension as critical.

> Microsoft attempted to solve the same type of issue at one stage by introducing application policies with exclude and include logic. It never got used.

Maybe it was not used while you were at Microsoft, but the message to the PKIX list that started this discussion shows that the current EKU is being used in the same manner as permittedKeyPurposeIds in my proposal.  Your example about constraining code signing is exactly the reason that I included excludedKeyPurposeIds in my proposal.

Russ

---

From: Stefan Santesson <[email-masked]>
Date: Mon, 23 May 2016 23:09:34 +0200

Russ,

In line;

>     Conforming CAs MUST mark this extension as critical.

Those where other times. That was extensions already known to the market. And we where more naïve at the time than we are today.
We overestimated the value of the features and we underestimated the interop challenges.
You are of course absolutely right. The only problem is that it may not work because it’s a deployment blocker. Who will include an extension that guarantees that the certificate will be rejected in all major implementations?

I’d make it a CA choice. They can decide whether they can live with the risk of clients not getting the extension constraint over the drawback of having the certificate rejected in most current clients.
This is no worse than it is today. Issuers putting in EKU in CA certificates for the purpose of constraining have no guarantee that everyone will get it, and obviously they can live with that.

>Maybe it was not used while you were at Microsoft, but the message to the PKIX list that started this discussion shows that the current EKU is being used in the same manner as permittedKeyPurposeIds…

The logic used for code signing only needs the permitted logic. Everything not in the permitted group is not permitted.
If I need to choose between 2 evils, I’d rather have a simple extension making it legal what is already out there, than a new fancy extension that is more capable.

/Stefan

---

From: Russ Housley <[email-masked]>
Date: Tue, 24 May 2016 16:11:38 -0400

> You are of course absolutely right. The only problem is that it may not work because it’s a deployment blocker. Who will include an extension that guarantees that the certificate will be rejected i…

Indeed, there are challenges to deploying a critical extension.  A significant population of relying parties would need to support it before a CA would make use of it.

> This is no worse than it is today. Issuers putting in EKU in CA certificates for the purpose of constraining have no guarantee that everyone will get it, and obviously they can live with that.

I think you are suggesting:

   This extension MAY, at the option of the certificate issuer, be
   either critical or non-critical.

If this is the approach supported by otters, then I will make the change.  It would require a bit of text in the Security Considerations about non-critical EKU constraints being ignored by relying parties that do not support this extension.

> If I need to choose between 2 evils, I’d rather have a simple extension making it legal what is already out there, than a new fancy extension that is more capable.

I’ve shared my thought process.  What do others think?

Russ

---

From: "Santosh Chokhani" <[email-masked]>
Date: Tue, 24 May 2016 16:39:27 -0400

If we are going to have the new extension and the application developers
will process it, it is better to have both permitted and excluded, albeit a
CHOICE.

The reason both is good is that way a CA can deny some and permit the rest
without having to spell all the permitted ones out.

The reason it should be a CHOICE is once a CA decides on permitted,
everything else is excluded.

Thus you will never need both.

Unlike name constraints (which is a continuous space and you may wish to
create holes in it using both), key purposes are independent, discreet
values and thus do not need both permitted and excluded.

-----Original Message-----
From: Spasm [mailto:[email-masked]] On Behalf Of Russ Housley
Sent: Tuesday, May 24, 2016 4:12 PM
To: Stefan Santesson <[email-masked]>
Cc: [email-masked]
Subject: Re: [Spasm] draft-housley-spasm-eku-constraints-01.txt

Stefan:

>>> 1) I don’t like that this extension MUST be critical. It’s a deployment
killer. Who can include it before all validation engines support it, and who
will bother to support it when no one includes it?
>> 
>> We have had this same debate with other must-be-critical extensions.  RFC
5280 has set the precedent on criticality for an extension in a CA
certificate that impose restrictions on things that can appear in subsequent
certificates in the path:
> Those where other times. That was extensions already known to the market.
And we where more naïve at the time than we are today.
> You are of course absolutely right. The only problem is that it may not
work because it’s a deployment blocker. Who will include an extension that
guarantees that the certificate will be rejected in all major
implementations?

Indeed, there are challenges to deploying a critical extension.  A
significant population of relying parties would need to support it before a
CA would make use of it.

> I’d make it a CA choice. They can decide whether they can live with the
risk of clients not getting the extension constraint over the drawback of
having the certificate rejected in most current clients.
> This is no worse than it is today. Issuers putting in EKU in CA
certificates for the purpose of constraining have no guarantee that everyone
will get it, and obviously they can live with that.

If this is the approach supported by otters, then I will make the change.
It would require a bit of text in the Security Considerations about
non-critical EKU constraints being ignored by relying parties that do not
support this extension.

> 
>> Maybe it was not used while you were at Microsoft, but the message to the
PKIX list that started this discussion shows that the current EKU is being
used in the same manner as permittedKeyPurposeIds in my proposal.  Your
example about constraining code signing is exactly the reason that I
included excludedKeyPurposeIds in my proposal.
> 
> The logic used for code signing only needs the permitted logic. Everything
not in the permitted group is not permitted.
> If I need to choose between 2 evils, I’d rather have a simple extension
making it legal what is already out there, than a new fancy extension that
is more capable.

Russ

---

From: Stefan Santesson <[email-masked]>
Date: Wed, 25 May 2016 10:30:07 +0200

Yes, that is what I would suggest.

I think it’s a matter of preference, not right or wrong.

I’d like to hear what those who will implement and use this think about it.

Unfortunately X.509 is over engineered and therefore many features are broken in practice.

Even if certificate using systems gets it right, certificate issuers don’t. So certificate using systems creates exceptions to the standards to handle non conformant certs.

Certificate policy in path processing is an excellent example.

I’d therefore rather give the market something I believe they can handle.

/Stefan

---

From: Wei Chuang <[email-masked]>
Date: Wed, 25 May 2016 10:43:21 -0700

On Tue, May 24, 2016 at 1:11 PM, Russ Housley <[email-masked]> wrote:

> Stefan:
> ...
> >
> > Those where other times. That was extensions already known to the
> market. And we where more naïve at the time than we are today.
> certificates for the purpose of constraining have no guarantee that
> everyone will get it, and obviously they can live with that.
>

I agree allowing for non-critical is a good approach to resolve the
deployment problems that Stefan has pointed out.  Non-critical would assist
bridging a transition.  Also at some future point, its would be possible to
revise again to make this extension critical once a significant population
uses it.

>
> >
> >> Maybe it was not used while you were at Microsoft, but the message to
> the PKIX list that started this discussion shows that the current EKU is
> being used in the same manner as permittedKeyPurposeIds in my proposal.
> Your example about constraining code signing is exactly the reason that I
> > The logic used for code signing only needs the permitted logic.
> Everything not in the permitted group is not permitted.

I think Stefan's simplification would be better for deployment.  There are
already many existing server certificates with intermediate CA EKU
constraints in their path.

-Wei

---

From: Sean Leonard <[email-masked]>
Date: Wed, 25 May 2016 11:06:45 -0700

On 5/25/2016 10:43 AM, Wei Chuang wrote:
>
>
> On Tue, May 24, 2016 at 1:11 PM, Russ Housley <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Stefan:
>     ...
>     >
>     > Those where other times. That was extensions already known to
>     the market. And we where more naïve at the time than we are today.
>     > You are of course absolutely right. The only problem is that it
>     may not work because it’s a deployment blocker. Who will include
>     an extension that guarantees that the certificate will be rejected
>     in all major implementations?
>
>     significant population of relying parties would need to support it
>     before a CA would make use of it.
>
>     > I’d make it a CA choice. They can decide whether they can live
>     with the risk of clients not getting the extension constraint over
>     the drawback of having the certificate rejected in most current
>     clients.
>     certificates for the purpose of constraining have no guarantee
>     that everyone will get it, and obviously they can live with that.
>
>     If this is the approach supported by otters, then I will make the
>     change.  It would require a bit of text in the Security
>     Considerations about non-critical EKU constraints being ignored by
>     relying parties that do not support this extension.
>
>
> deployment problems that Stefan has pointed out.  Non-critical would 
> assist bridging a transition. Also at some future point, its would be 
> possible to revise again to make this extension critical once a 
> significant population uses it.

I support a transitional period baked into the draft, namely, that the 
extension MAY be critical now; SHOULD be critical after time X (2018?), 
and MUST be critical after time Y (2020?).

Perhaps the time should be tied to the certificate issuance artifact, 
namely, where the notBefore date is prior to X, then MAY; if notBefore 
is prior to Y, then SHOULD; if notBefore is after Y, then MUST.

Sean

---

From: Stefan Santesson <[email-masked]>
Date: Wed, 25 May 2016 22:59:49 +0200

I don’t like transition periods. They assume things we do not know anything about.

Most importantly they assume that this extension gets deployed widely.

What if that doesn’t happen but some still use it successfully with non-criticality?

We don’t know if the conditions of today will go away tomorrow.

/Stefan

From: Spasm <[email-masked]> on behalf of Sean Leonard <[email-masked]>
Date: Wednesday 25 May 2016 at 20:06
To: <[email-masked]>
Subject: Re: [Spasm] draft-housley-spasm-eku-constraints-01.txt

 

Stefan:
...

I agree allowing for non-critical is a good approach to resolve the deployment problems that Stefan has pointed out.  Non-critical would assist bridging a transition.  Also at some future point, its would be possible to revise again to make this extension critical once a significant population uses it.

I support a transitional period baked into the draft, namely, that the extension MAY be critical now; SHOULD be critical after time X (2018?), and MUST be critical after time Y (2020?).

Perhaps the time should be tied to the certificate issuance artifact, namely, where the notBefore date is prior to X, then MAY; if notBefore is prior to Y, then SHOULD; if notBefore is after Y, then MUST.

Sean 

_______________________________________________ Spasm mailing list [email-masked] https://www.ietf.org/mailman/listinfo/spasm

---

From: Stefan Santesson <[email-masked]>
Date: Wed, 25 May 2016 23:15:55 +0200

There is one more argument for the alternative solution to just set a binary value that declares that EKU in CA certs have a constraining property. (compatible with many current CA certs)

The advantage with this is that this bit could also be added as an input parameter to path processing, when the certs in use don’t have them yet.

That would make it legal do do this constraining processing on existing certs that do not yet have this new extension included.

We all know how hard and costly it can be to re-issue CA certificates.

We will therefore have to live with old non-compliant certificates for a long time (some of these certificates are very long lived).

Microsoft have/had property settings for trusted certificates in cert stores, which are passed as input parameters to path processing.

If the extension we define is just a binary value that endorses the current intended constraining effect of EKUs in CA certificates, then that would be more compatible with passing the same logic through property parameters in cert stores as backup for certificates that don’t have this extension yet.

It is not so clear to me what the comparable situation would be with the new extension.

The risk is that there will be a mess with different ways to constrain in the same path. 

-          Property parameter in the cert store suggest some EKU constraining

-          Some CA certs in the path constrain through EKU extenson

-          Some CA certs in the path contstain through the new extension.

The risk is that two implementers will do this with incompatible results.

/Stefan

 

From: Spasm <[email-masked]> on behalf of Wei Chuang <[email-masked]>
Date: Wednesday 25 May 2016 at 19:43
To: Russ Housley <[email-masked]>
Cc: <[email-masked]>, Stefan Santesson <[email-masked]>
Subject: Re: [Spasm] draft-housley-spasm-eku-constraints-01.txt

I think Stefan's simplification would be better for deployment.  There are already many existing server certificates with intermediate CA EKU constraints in their path.

---

From: Russ Housley <[email-masked]>
Date: Thu, 26 May 2016 15:34:21 -0400

> If I need to choose between 2 evils, I’d rather have a simple extension making it legal what is already out there, than a new fancy extension that is more capable.

The use case that is motivating the excludedKeyPurposeIds field is the isolation of very special capabilities like code signing.  The current approach dies not do that well.  Let’s look at a way to do it with the extension as it is defined in the current draft. Starting with an unconstrained root, two Intermediate CA certs are issued.  The first one will be exclusively for code signing certificates, and the second one for everything else.

	ICA1 will have a EKU constraint that has permitted key purpose for code signing and OCSP signing.

	ICA2 will have a EKU constraint that has excluded key purpose for code signing.

The approach used today does not provide this clean separation, and the allocation of new key purpose identifiers can lead to new certificates being issues to enable them.

Russ

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 26 May 2016 20:38:49 +0100

Hi Russ,

On 26/05/16 20:34, Russ Housley wrote:
> The use case that is motivating the excludedKeyPurposeIds field is
> the isolation of very special capabilities like code signing.  The
> current approach dies not do that well.

Would it be good to put something along those lines in the charter
text?

Say "There is a need to isolate some special capabilities enabled
via PKI from more "normal" end-entity authentication, with the main
use case here being separation of code-signing from web-server
authentication so that relying parties are not as easily confused
between the two."

I'm sure the wording needs improving (I'd welcome better from anyone
on the list) but adding something like that is what I was asking about
in the scoping thread.

Cheers,
S.

---

From: Russ Housley <[email-masked]>
Date: Thu, 26 May 2016 16:33:31 -0400

> on the list) but adding something like that is what I was asking about

I guess I'm hoping to hear whether any CA believes in this use case.  The answer to that will tell us whether this meets your deployability requirement.

Russ

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 26 May 2016 21:35:46 +0100

On 26/05/16 21:33, Russ Housley wrote:
> Stephen:
> 
>> 
>>> The use case that is motivating the excludedKeyPurposeIds field
>>> is the isolation of very special capabilities like code signing.
>>> The current approach dies not do that well.
>> 
>> via PKI from more "normal" end-entity authentication, with the
>> main use case here being separation of code-signing from
>> web-server authentication so that relying parties are not as easily
>> confused between the two."
>> 
>> I'm sure the wording needs improving (I'd welcome better from
>> anyone on the list) but adding something like that is what I was
>> asking about in the scoping thread.
> 
> I guess I'm hoping to hear whether any CA believes in this use case.
> The answer to that will tell us whether this meets your deployability
> requirement.

Yes, that'd be good to know. That's a similar point to Richard's
too I guess. I assume we have some folks on here who could ask
the CABForum folks if they'd want this, or maybe there are other
CAs on here who'd be willing to say they'd be interested in
updating their stuff for this.

Cheers,
S.

> 
> Russ
> 
> 
> 
> _______________________________________________ Spasm mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/spasm
>

---

From: Laetitia Baudoin <[email-masked]>
Date: Thu, 26 May 2016 13:48:48 -0700

> updating their stuff for this.

Hasn't the CABForum already settled on using the EKU extensions in
intermediate CA certificates as a way to constrain the uses?
For example:
---
In https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.3.4.pdf
For a Subordinate CA 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 Certificate is
authorized to issue certificates for. The anyExtendedKeyUsage KeyPurposeId
MUST NOT appear within this extension.
---