Subject: [Spasm] My take on handling EKU constraints

From: Russ Housley <[email-masked]>
Date: Fri, 13 May 2016 19:17:37 -0400

Review and comment are most welcome.

Russ

= = = = = = = = = =

A new version of I-D, draft-housley-spasm-eku-constraints-00.txt
has been successfully submitted by Russell Housley and posted to the
IETF repository.

Name:		draft-housley-spasm-eku-constraints
Revision:	00
Title:		Extended Key Usage Constraints
Document date:	2016-05-13
Group:		Individual Submission
Pages:		5
URL:            https://www.ietf.org/internet-drafts/draft-housley-spasm-eku-constraints-00.txt
Status:         https://datatracker.ietf.org/doc/draft-housley-spasm-eku-constraints/
Htmlized:       https://tools.ietf.org/html/draft-housley-spasm-eku-constraints-00

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 subsequent
  certificates in a certification path.  Restrictions apply to the
  extended key usage certificate extension, which is described in RFC
  5280.

---

From: "Santosh Chokhani" <[email-masked]>
Date: Sun, 15 May 2016 21:12:57 -0400

Hi Russ,

Thanks for doing this.

Here are my comments on the draft.

1.  You are requiring the extension to be critical.  This may cause denial
of service during the transition stage while the application implement the
processing logic.  May be start with RECOMMENDED to be critical and then
transition to SHALL be critical when there is wider support for the
extension.

2.  The language at the end of Section 2 regarding extension processing and
tying it to criticality does not seem right to me.  Criticality of extension
should not impact its processing  It also relates to my concerns regarding
wrap up procedure in Section 3.  I would like the criticality part removed.

3.  Now to the wrap up procedure in Section 3, I would recommend taking an
intersection of permitted EKU Constraint State and EKU in the end
certificate and then deleting the EKUs in the result that are in the
excluded EKU Constraint State.  Now, the resulting EKU set should be
returned to the application for enforcement.  It is quite possible that some
applications do not care about EKUs at all.  I could live with if the group
decides if the resulting EKU set is null, it is a path validation failure.
But, my preference is for the application to enforce it.

I will let you respond to Jim Schaad, but I do not either understand his
comments or I do not agree with him.

On 1, to my knowledge the AA certificate is the end certificate in PKI
certification path and hence I do not see how EKU constraints in that
certificate is applicable.

On 2, I have some empathy, but that can also be enforced by the application
per what I suggest above.  I do not have any objection to Jim's approach
either.

I do not get his 3.  I see the path validation engine and associated state
variables accurate.

-----Original Message-----
From: Spasm [mailto:[email-masked]] On Behalf Of Russ Housley
Sent: Friday, May 13, 2016 7:18 PM
To: [email-masked]
Subject: [Spasm] My take on handling EKU constraints

Russ

= = = = = = = = = =

A new version of I-D, draft-housley-spasm-eku-constraints-00.txt
has been successfully submitted by Russell Housley and posted to the IETF
repository.

Name:		draft-housley-spasm-eku-constraints
Revision:	00
Title:		Extended Key Usage Constraints
Document date:	2016-05-13
Group:		Individual Submission
Pages:		5
URL:
https://www.ietf.org/internet-drafts/draft-housley-spasm-eku-constraints-00.
txt
Status:
https://datatracker.ietf.org/doc/draft-housley-spasm-eku-constraints/
Htmlized:
https://tools.ietf.org/html/draft-housley-spasm-eku-constraints-00

Abstract:

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

---

From: "Santosh Chokhani" <[email-masked]>
Date: Sun, 15 May 2016 21:34:57 -0400

One more comment.

The I-D should address anyExtendedKeyUsage.  Either it should be prohibited
from the permitted or excluded or the path validation engine should treat
this value in either field as the UNIVERSAL set.

Ideally path validation engine will address it for both fields and the I-D
would discourage its assertion in either field.  I could see some value in
its assertion in excluded field, though.

-----Original Message-----
From: Santosh Chokhani [mailto:[email-masked]] 
Sent: Sunday, May 15, 2016 9:13 PM
To: 'Russ Housley' <[email-masked]>; [email-masked]
Subject: RE: [Spasm] My take on handling EKU constraints

Hi Russ,

Thanks for doing this.

-----Original Message-----
From: Spasm [mailto:[email-masked]] On Behalf Of Russ Housley
Sent: Friday, May 13, 2016 7:18 PM
To: [email-masked]
Subject: [Spasm] My take on handling EKU constraints

Russ

= = = = = = = = = =

Abstract:

---

From: "Santosh Chokhani" <[email-masked]>
Date: Sun, 15 May 2016 21:44:57 -0400

Sorry for not thinking of one more item:

Some discussion of OCSPSigning EKU in permitted field to accommodate
Delegated OCSP trust model will be useful.  May be in Security
Considerations Section.

-----Original Message-----
From: Santosh Chokhani [mailto:[email-masked]] 
Sent: Sunday, May 15, 2016 9:35 PM
To: 'Russ Housley' <[email-masked]>; [email-masked]
Subject: RE: [Spasm] My take on handling EKU constraints

One more comment.

-----Original Message-----
From: Santosh Chokhani [mailto:[email-masked]]
Sent: Sunday, May 15, 2016 9:13 PM
To: 'Russ Housley' <[email-masked]>; [email-masked]
Subject: RE: [Spasm] My take on handling EKU constraints

Hi Russ,

Thanks for doing this.

-----Original Message-----
From: Spasm [mailto:[email-masked]] On Behalf Of Russ Housley
Sent: Friday, May 13, 2016 7:18 PM
To: [email-masked]
Subject: [Spasm] My take on handling EKU constraints

Russ

= = = = = = = = = =

Abstract:

---

From: "Jim Schaad" <[email-masked]>
Date: Sun, 15 May 2016 22:11:05 -0700

-----Original Message-----
From: Spasm [mailto:[email-masked]] On Behalf Of Santosh Chokhani
Sent: Sunday, May 15, 2016 6:13 PM
To: 'Russ Housley' <[email-masked]>; [email-masked]
Subject: Re: [Spasm] My take on handling EKU constraints

Hi Russ,

Thanks for doing this.

[JLS] The current text states that that the AA certificate could not have an
EKU constraint extension to restrict how the AA certificates that it issues
can be used.  I believe that might be a useful case.

I do not get his 3.  I see the path validation engine and associated state
variables accurate.
[JLS] This does two things.  First if the empty permitted set is created,
then you can stop validation immediately and secondly, the EKU constraints
should be enforced even if there is not EKU in the leaf certificate being
validated. 

Jim

-----Original Message-----
From: Spasm [mailto:[email-masked]] On Behalf Of Russ Housley
Sent: Friday, May 13, 2016 7:18 PM
To: [email-masked]
Subject: [Spasm] My take on handling EKU constraints

Russ

= = = = = = = = = =

Abstract:

---

From: Sean Leonard <[email-masked]>
Date: Sun, 15 May 2016 23:16:18 -0700

Hello:

In the ASN.1 module (to be written), it's important to specify whether 
this extension uses IMPLICIT, EXPLICIT, or AUTOMATIC tagging. I am 
guessing folks don't want to use AUTOMATIC tagging, even though it's 
recommended by the latest ASN.1 standards because it's "easy". My 
personal preference is for EXPLICIT tagging. However, the extended key 
usage extension is defined in the IMPLICIT module in RFC 5280, so it's 
IMPLICIT...this means that if you want symmetry with the EKU extension, 
you should say it's IMPLICIT.

Is there a way, using the latest ASN.1 syntax, to specify 
"either-or-or-both", i.e., the EKUConstraints SEQUENCE must have at 
least one element, possibly two, but not zero?

As I understand it, "permitted" takes greater precedence over 
"excluded". I.e., if the extension has both permitted AND excluded, then 
really, only "permitted" is going to have meaningful effect.
1. That is because if a given EKU is on the permitted list but is also 
on the excluded list, it behaves as if it's not on the permitted list in 
the first place: effectively removing it from permitted.
2. If a given EKU is on the permitted list but NOT on the excluded list, 
then it's permitted: no additional effect.
3. If a given EKU is NOT on the permitted list but IS on the excluded 
list, then it's excluded, but this is the same as if it were not on the 
permitted list: no additional effect.
4. If a given EKU is on NEITHER the permitted list NOR the excluded 
list, this is the same as if it were not on the permitted list: no 
additional effect.

I could show fancy set theory math but am lazy. ;-)

Given the lazy-proof above, EKUConstraints does not need to be a 
SEQUENCE. It just needs to be a CHOICE between permittedKeyPurposeIDs 
and excludedKeyPurposeIDs. When it's tagged [0] on the wire, it means 
"permitted". When it's tagged [1] on the wire, it means "excluded". QED.

(Note: Instead of expressing EKUConstraints as a CHOICE, we could 
specify two extensions, identified by id-ce-permittedEKUConstraints and 
id-ce-excludedEKUConstraints. However I believe that the CHOICE is 
better because the CHOICE prevents an implementation from stuffing both 
extensions into a certificate.)

The appropriate ASN.1 standard and version should be referenced. Usually 
we use the 1988 syntax around these parts; however, that standard has 
been long superseded. Figure out what works for you...it appears that 
RFC 5280 references X.680 (2002), while 5280 was published in May 2008.

Sean

---

From: Michael Richardson <[email-masked]>
Date: Mon, 16 May 2016 09:13:41 -0400

Initial read had me confused by:

  Conforming CAs MUST mark this extension as critical, and conforming
  CAs MUST NOT issue certificates where this extension is an empty
  sequence.  That is, either the permittedKeyPurposeIds field or the
  excludedKeyPurposeIds field MUST be present.

vs:
  If the set is empty, then the
  certification path will be considered invalid if the end-entity
  certificate includes an extended key usage extension

I suggest initial paragraph be changed to:
  Conforming CAs MUST mark this extension as critical, and conforming
  CAs MUST NOT issue certificates where this extension is an empty
  sequence.  That is, either the permittedKeyPurposeIds field or the
  excludedKeyPurposeIds field MUST be present, but the field MAY contain
  an empty set.

typo:
  The initial value is a is the empty set.
  => The initial value is the empty set.

I see the AND/OR operation on permitted/excluded as the chain is walked.
Clearly an intermediate CA may issue an EKU that includes things that the
parent/root CA did not want to include, and that this is an anomaly, but not
an error.

With the SHA1->SHA256 roll I found it interesting that many root CAs
generated new SHA256 keys which they used to sign the intermediate CAs again,
and so one "upgrades" the chain not by replacing the entire chain, but by
just updating the root.  The same thing could be used here, with a root CA
signing an intermediate and providing different EKUs--- depending upon which
chain the validating end has, they could come to different conclusions.

I wonder if some discussion of this is meritted?  Is this a bug or a feature?

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: "Santosh Chokhani" <[email-masked]>
Date: Mon, 16 May 2016 09:42:51 -0400

HI Jim,

See in-line below.

-----Original Message-----
From: Jim Schaad [mailto:[email-masked]] 
Sent: Monday, May 16, 2016 1:11 AM
To: 'Santosh Chokhani' <[email-masked]>; 'Russ Housley'
<[email-masked]>; [email-masked]
Subject: RE: [Spasm] My take on handling EKU constraints

-----Original Message-----
From: Spasm [mailto:[email-masked]] On Behalf Of Santosh Chokhani
Sent: Sunday, May 15, 2016 6:13 PM
To: 'Russ Housley' <[email-masked]>; [email-masked]
Subject: Re: [Spasm] My take on handling EKU constraints

Hi Russ,

Thanks for doing this.

[JLS] The current text states that that the AA certificate could not have an
EKU constraint extension to restrict how the AA certificates that it issues
can be used.  I believe that might be a useful case.
[Santosh] I get that.  But, since EKU is part of PKI and not PMI, it would
be better to restrict the end entity.  I have no objection  to plain EKU in
AA certificate.  AA should only constrain the attributes and EKU is not one
of the attributes unless it wanted to do so via defining this as an
attribute in attribute certificate. 

I do not get his 3.  I see the path validation engine and associated state
variables accurate.
[JLS] This does two things.  First if the empty permitted set is created,
then you can stop validation immediately and secondly, the EKU constraints
should be enforced even if there is not EKU in the leaf certificate being
validated. 
[Santosh] I am not in favor of causing path validation failure due to empty
EKU.  Some applications do not care.  EKU should be enforced by the
application just like KU.  See my suggestion 3 above for wrap up.  I think
the path validation engine should output EKUs and let the application do the
enforcement.  We do the same for certificate policy unless require explicit
policy state variable gets set by the state machine.  I do not think we want
this added state variable for EKU and initial value and added value in the
extension.  It is better to let the application make its own decision.

Jim

-----Original Message-----
From: Spasm [mailto:[email-masked]] On Behalf Of Russ Housley
Sent: Friday, May 13, 2016 7:18 PM
To: [email-masked]
Subject: [Spasm] My take on handling EKU constraints

Russ

= = = = = = = = = =

Abstract:

---

From: "Santosh Chokhani" <[email-masked]>
Date: Mon, 16 May 2016 09:47:57 -0400

Hi Sean,

It is more complicated and more flexible than what you say due to the path.

As you go through the path, the permitted can remain the same or only shrink
and excluded can stay the same and grow and at the end you remove from the
end certificate EKU which are not in the permitted state variable and are in
the excluded state variable.

So, what is being proposed here is flexible and secure.

-----Original Message-----
From: Spasm [mailto:[email-masked]] On Behalf Of Sean Leonard
Sent: Monday, May 16, 2016 2:16 AM
To: [email-masked]
Subject: Re: [Spasm] My take on handling EKU constraints

Hello:

In the ASN.1 module (to be written), it's important to specify whether this
extension uses IMPLICIT, EXPLICIT, or AUTOMATIC tagging. I am guessing folks
don't want to use AUTOMATIC tagging, even though it's recommended by the
latest ASN.1 standards because it's "easy". My personal preference is for
EXPLICIT tagging. However, the extended key usage extension is defined in
the IMPLICIT module in RFC 5280, so it's IMPLICIT...this means that if you
want symmetry with the EKU extension, you should say it's IMPLICIT.

Is there a way, using the latest ASN.1 syntax, to specify
"either-or-or-both", i.e., the EKUConstraints SEQUENCE must have at least
one element, possibly two, but not zero?

As I understand it, "permitted" takes greater precedence over "excluded".
I.e., if the extension has both permitted AND excluded, then really, only
"permitted" is going to have meaningful effect.
1. That is because if a given EKU is on the permitted list but is also on
the excluded list, it behaves as if it's not on the permitted list in the
first place: effectively removing it from permitted.
2. If a given EKU is on the permitted list but NOT on the excluded list,
then it's permitted: no additional effect.
3. If a given EKU is NOT on the permitted list but IS on the excluded list,
then it's excluded, but this is the same as if it were not on the permitted
list: no additional effect.
4. If a given EKU is on NEITHER the permitted list NOR the excluded list,
this is the same as if it were not on the permitted list: no additional
effect.

Given the lazy-proof above, EKUConstraints does not need to be a SEQUENCE.
It just needs to be a CHOICE between permittedKeyPurposeIDs and
excludedKeyPurposeIDs. When it's tagged [0] on the wire, it means
"permitted". When it's tagged [1] on the wire, it means "excluded". QED.

(Note: Instead of expressing EKUConstraints as a CHOICE, we could specify
two extensions, identified by id-ce-permittedEKUConstraints and
id-ce-excludedEKUConstraints. However I believe that the CHOICE is better
because the CHOICE prevents an implementation from stuffing both extensions
into a certificate.)

The appropriate ASN.1 standard and version should be referenced. Usually we
use the 1988 syntax around these parts; however, that standard has been long
superseded. Figure out what works for you...it appears that RFC 5280
references X.680 (2002), while 5280 was published in May 2008.

Sean

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 16 May 2016 15:01:57 +0100

Hi Santosh,

A sort of meta comment below...

> extension.  It is better to let the application make its own decision.

I hope we all agree that this kind of thing ought be mostly
driven by what those implementing or deploying certificate
validation and applications want and are willing to do and
what they think makes sense in terms of APIs etc. For example,
I wondered which application(s) you are involved in developing
you meant in the above.

One thing I think we need to be quite careful about with all
of this planned work is to not repeat mistakes we (incl. me)
made in the past where we designed a bunch of PKI machinery
that didn't get used, or that made it harder to use PKI, or
that made PKI less useful. There is really no point in us
repeating such mistakes, and again, I hope we all agree on
that.

So I'd much prefer that we see arguments on this that look
more like "In my application/library <foo>, I'd prefer we do
it <this> way, because..."

Cheers,
S.

---

From: Sean Leonard <[email-masked]>
Date: Mon, 16 May 2016 08:22:28 -0700

Hi Santosh,

With respect to the permitted/excluded issue: I read through the draft 
again, and disagree with the assertion that "it is more complicated and 
more flexible than what you say due to the path".

Sure the algorithm is more complicated in draft-00 than what I'm saying, 
but it is not more flexible. The result is the same. The draft says:
Section 3.5:

         (1)  If permitted_key_purpose_ids state variable is not special
              value that represents the universal set, then confirm that
              all of the key purpose identifiers/[in the EKU extension////of the end-entity certificate]/
              are present in the set.
              If any are missing, then returning a failure indication and
              an appropriate reason.

That is the same result. So the structures and algorithms proposed in 
draft-00 are needlessly complicated. (Specifically the structures, and 
enforcement of the structures, are needlessly complicated. I am not sure 
if the algorithm state variables can be reduced; need to think about it 
more. Offhand, I think that it could be shown that you need the same 
state variables as the structure, i.e., one boolean indicating whether 
we are in permitted vs. excluded mode, and one set of key purpose IDs. 
Once the algorithm encounters a "permitted" extension, it should flip 
the boolean from excluded to permitted, and do the difference of the 
excluded IDs to the permitted IDs.)

I request a counter-proof.

Sean

---

From: "Santosh Chokhani" <[email-masked]>
Date: Mon, 16 May 2016 11:45:54 -0400

Hi Steve,

I have been dealing with EKU dilemma based on how Microsoft treats absence
of 
EKU and how it can cause certificates to be treated as code signer.

I have been advising several customers on how to mitigate this problem and 
what kind of interoperability and standard compliance problem it causes for 
the various platforms and applications when you use EKU in intermediate 
certificates or use Application Policies extension which is a private 
Microsoft extension, has the same semantics, but different syntax and has
been 
deprecated lately to the best my knowledge.

The specific text you cite below is a natural outcome when you think that
the 
EKU should be enforced at the application layer and not at the path
validation 
layer.

-----Original Message-----
From: Stephen Farrell [mailto:[email-masked]]
Sent: Monday, May 16, 2016 10:02 AM
To: Santosh Chokhani <[email-masked]>; 'Jim Schaad' 
<[email-masked]>; 'Russ Housley' <[email-masked]>; 
[email-masked]
Subject: Re: [Spasm] My take on handling EKU constraints

Hi Santosh,

Cheers,
S.

---

From: "Santosh Chokhani" <[email-masked]>
Date: Mon, 16 May 2016 12:06:03 -0400

Hi Sean,

If you mean that each CA certificate needs to have only one or the other
permitted or excluded and the validation engine needs only one state
variable, I agree.

Say, you can keep a list of permitted only as state variable and delete
excluded ones when they appear and take the intersection with permitted one
when it appears.  There will be an edge case if excluded has
anyExtendedKeyUsage and in that case permitted set becomes NULL.

I still think this new logic should not cause failure and wrap up should
take intersection of the permitted state variable and EKU in the end
certificate with absence of extension being treated as UNIVERSAL set.

Does that work and do I get you now?

From: Spasm [mailto:[email-masked]] On Behalf Of Sean Leonard
Sent: Monday, May 16, 2016 11:22 AM
To: [email-masked]
Subject: Re: [Spasm] My take on handling EKU constraints

Hi Santosh,

With respect to the permitted/excluded issue: I read through the draft
again, and disagree with the assertion that "it is more complicated and more
flexible than what you say due to the path".

Sure the algorithm is more complicated in draft-00 than what I'm saying, but
it is not more flexible. The result is the same. The draft says:
Section 3.5:

        (1)  If permitted_key_purpose_ids state variable is not special
             value that represents the universal set, then confirm that
             all of the key purpose identifiers [in the EKU extension
             of the end-entity certificate]
             are present in the set.
             If any are missing, then returning a failure indication and
             an appropriate reason.

That is the same result. So the structures and algorithms proposed in
draft-00 are needlessly complicated. (Specifically the structures, and
enforcement of the structures, are needlessly complicated. I am not sure if
the algorithm state variables can be reduced; need to think about it more.
Offhand, I think that it could be shown that you need the same state
variables as the structure, i.e., one boolean indicating whether we are in
permitted vs. excluded mode, and one set of key purpose IDs. Once the
algorithm encounters a "permitted" extension, it should flip the boolean
from excluded to permitted, and do the difference of the excluded IDs to the
permitted IDs.)

Sean

Hi Sean,

 
 
-----Original Message-----
From: Spasm [mailto:[email-masked]] On Behalf Of Sean Leonard
Sent: Monday, May 16, 2016 2:16 AM
To: [email-masked] <mailto:[email-masked]> 
Subject: Re: [Spasm] My take on handling EKU constraints
 
Hello:

 

 

Sean

 
Russ
 
= = = = = = = = = =

Status:

Htmlized:

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

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

---

From: Russ Housley <[email-masked]>
Date: Mon, 16 May 2016 17:12:26 -0400

> transition to SHALL be critical when there is wider support for the

I thought about this.  The logic that was used in the past was that the constraints can be ignored if they are not critical.  I’m not sure which is worse.

> wrap up procedure in Section 3.  I would like the criticality part removed.

This seems like the same as comment 1.

> But, my preference is for the application to enforce it.

As I said in my response to Jim, I was trying to not impact the API to the certification path validation library.  This would be a significant change.  It would trim the set if key purpose ids in the end-entity certificate to those that meet the restrictions.  It is easy to add to the specification, but it is harder to get deployed in applications.

What do others think?

Russ

---

From: Russ Housley <[email-masked]>
Date: Mon, 16 May 2016 17:13:49 -0400

> this value in either field as the UNIVERSAL set.

I’d prefer to treat anyPurpose just like every other OID as far as the constraints are concerned.

	If it is in the excluded set, then is cannot appear.
	If it is in the permitted set, then it can appear.

What do others think?

Russ

---

From: Russ Housley <[email-masked]>
Date: Mon, 16 May 2016 17:16:41 -0400

> Delegated OCSP trust model will be useful.  May be in Security

We could add a discussion about the consequences of a particular EKU in the end-entity certificate, but I cannot see why that is needed here.  You seem to be thinking about some specific concern, please say more.

Russ

---

From: Russ Housley <[email-masked]>
Date: Mon, 16 May 2016 17:22:04 -0400

On May 16, 2016, at 2:16 AM, Sean Leonard <[email-masked]> wrote:

> Hello:
> 
> In the ASN.1 module (to be written), it's important to specify whether this extension uses IMPLICIT, EXPLICIT, or AUTOMATIC tagging. I am guessing folks don't want to use AUTOMATIC tagging, even though it's recommended by the latest ASN.1 standards because it's "easy". My personal preference is for EXPLICIT tagging. However, the extended key usage extension is defined in the IMPLICIT module in RFC 5280, so it's IMPLICIT...this means that if you want symmetry with the EKU extension, you should say it's IMPLICIT.

I was assuming that IMPLICIT would be used.

> Is there a way, using the latest ASN.1 syntax, to specify "either-or-or-both", i.e., the EKUConstraints SEQUENCE must have at least one element, possibly two, but not zero?

The text already says that.

> As I understand it, "permitted" takes greater precedence over "excluded". I.e., if the extension has both permitted AND excluded, then really, only "permitted" is going to have meaningful effect.

No, the text says that if the key purpose is the the excluded set, then it is excluded.

To resolve Jim’s comments I suggested:

   (h)  If the EKU extension is included in the end-entity certificate,
        then confirm that the values meet the restrictions in the
        permitted_key_purpose_ids and excluded_key_purpose_ids state
        variables as follows:

        (1)  If excluded_key_purpose_ids state variable is empty, then
             return a failure indication and an appropriate reason.

        (2)  If excluded_key_purpose_ids state variable is not empty,
             then confirm that none of the key purpose identifiers are
             present in the set.  If any are present, then return a
             failure indication and an appropriate reason.

        (3)  If permitted_key_purpose_ids state variable is not special
             value that represents the universal set, then confirm that
             all of the key purpose identifiers are present in the set.
             If any are missing, then returning a failure indication and
             an appropriate reason.

Russ

---

From: Russ Housley <[email-masked]>
Date: Mon, 16 May 2016 17:27:51 -0400

>  excludedKeyPurposeIds field MUST be present, but the field MAY contain

That is not what I’m trying to say.

    EKUConstraints ::= SEQUENCE {
       permittedKeyPurposeIds   [0] KeyPurposeIds OPTIONAL,
       excludedKeyPurposeIds    [1] KeyPurposeIds OPTIONAL }

The SEQUNCE has two optional things.  One or the other or both must be present.

>  => The initial value is the empty set.

Fixed.

> I wonder if some discussion of this is meritted?  Is this a bug or a feature?

I do not think this is different than the situation with name constraints or policy constraints in RFC 5280.

I do not know if it needs highlighted.

Russ

---

From: Sean Leonard <[email-masked]>
Date: Mon, 16 May 2016 20:56:06 -0700

> I was assuming that IMPLICIT would be used.

Ok; IMPLICIT needs to be in the next draft then.

> The text already says that.

The text does, but not the ASN.1. I.e., an ASN.1 compiler can't enforce 
the constraint as written in the text. I see that as a flaw.

> No, the text says that if the key purpose is the the excluded set, then it is excluded.

I see how what I wrote could be misinterpreted; sorry about that. Of 
course if the key purpose is in the excluded set, then it is excluded. 
In that sense, an excluded OID takes precedence over the same OID being 
in the permitted set.

The point is that putting an OID on both lists is pointless and 
needlessly complicated. If an OID is on the permitted list AND the 
excluded list, then, why is it on either list at all?

Section 3.5 (h) (i) says:

The permitted set of OIDs can, apparently, be: "infinity" (unbounded), 
"nonzero" (finite: bounded to only those listed), or "none" (zero). The 
moment ANY certificate in the path mentions a permitted set, you are 
forever thrown out of "infinity". It is now finite. Possibly zero. So 
the effect of having further excluded sets (after introducing the first 
permitted set), is only to whittle away at the finite permitted set of 
OIDs. You may as well either repeat the list of permitted EKUs, or 
whittle it down in the next certificate in the chain. Mentioning 
excluded sets only makes sense at the top of the chain, before the first 
"permitted set" is introduced.

Example: consider a single CA cert in the chain that mentions both 
permitted and excluded:
{
permitted:
1.1.1.1
1.1.1.2

excluded:
1.1.1.2
1.1.1.3
1.1.1.4
}

If only 1.1.1.1 and 1.1.1.2 are permitted, then mentioning 1.1.1.3 and 
1.1.1.4 as "excluded" serves no purpose. You may as well drop 1.1.1.3 
and 1.1.1.4. Furthermore, since 1.1.1.2 is excluded, why bother 
mentioning it in "permitted"? That likewise serves no purpose. You may 
as well have said:

{
permitted:
1.1.1.1
}

and have been done with it.

Mentioning the excluded set at all, only makes sense when there is no 
defined permitted set (i.e., the permitted set is the "special value 
that represents the universal set"). In that way, excluding those OIDs 
basically means we have the universal set ("infinity") MINUS a few 
mentioned OIDs.

That is why I am (increasingly) harping on making this extension a 
CHOICE, rather than a SEQUENCE that can permit both.

Sean

---

From: Sean Leonard <[email-masked]>
Date: Mon, 16 May 2016 21:21:59 -0700

On 5/16/2016 7:01 AM, Stephen Farrell wrote:
> [...]
> that made PKI less useful.
I really want to channel Stephen here on this point about avoiding 
making algorithms too complicated, that people won't use.

Sure it is possible to write algorithms that do all this 
"intersectionality" and "differential" stuff with permitted and excluded 
items. But maybe it doesn't make real-world sense (as we have seen with 
lackluster support for Name Constraints).

Taking a step back, I question the need for the excluded set. By 
default, a trust anchor that is defined purely by a certificate (i.e., a 
self-signed, self-issued one, one under the control of the trust anchor 
party) will naturally "want" universal capabilities: it is more 
economically valuable. Of course if I create a CA for my own purposes, I 
will imbue it with universal trust. I wouldn't exclude myself from 
issuing certs for specific applications.

The situation changes when the trust point delegates its authority to 
the next guy down the line (aka, issues a certificate). I want to be 
sure that the next guy doesn't abuse my universal authority, so I want 
to constrain him/her/it. Therefore, I say: "you can do these enumerated 
things, but I'm not giving you a blank check". Specifying an excluded 
set is tantamount to writing an /almost/ blank check: "you can put any 
number in the amount field, just as long as it's not one million, or 
four billion". Not a good situation. Principle of least privilege, folks.

Now it is possible (in fact, quite likely) that a certificate-using 
application will want to exclude purposes entirely from the path. Maybe 
the user (or sysadmins) "trust" some CA for what it contractually claims 
to limit itself to issue, but no matter what, the user is never going to 
"trust" that CA for "Kernel Mode Signing". That exclusion is perfectly 
valid (and perhaps can be specified in the path processing algorithm, 
especially at the "top"), but is not part of the artifacts in the 
certification path itself.

The way that I understand how the Microsoft EKU implementation works, is 
that it's a funnel of permitted usages only. At the topmost level, the 
user/application says exactly what EKUs it will allow the trust anchor 
to promulgate: everything ("Enable all purposes for this certificate"), 
nothing ("Disable all purposes for this certificate"), or exactly a 
finite list of specific things ("Enable only the following purposes: 
[OIDs]"). At each step in the certification path, the cert can contract 
the set of usages, but cannot expand them. What is effective at the 
end-entity certificate is just the intersection of all permitted usages. 
The dialog box says: "Note: you may only edit the certificate purposes 
that are allowed by the certification path."

We can make things a lot simpler if we make this EKU Constraints 
extension just be a list of permittedKeyPurposeIds, in which case, it 
would be syntactically identical to ExtKeyUsageSyntax.

I would also posit that Name Constraints would be a lot easier to 
implement, and a lot more useful, if they were defined as "permitted" 
only, for analogous reasons.

(I have no comment or insight on certificate policies, other than, a lot 
of people find them awfully complicated.)

Sean

---

From: "Santosh Chokhani" <[email-masked]>
Date: Tue, 17 May 2016 09:26:21 -0400

Hi Russ,

See below in-line.

-----Original Message-----
From: Russ Housley [mailto:[email-masked]] 
Sent: Monday, May 16, 2016 5:12 PM
To: Santosh Chokhani <[email-masked]>
Cc: [email-masked]
Subject: Re: [Spasm] My take on handling EKU constraints

On May 15, 2016, at 9:12 PM, Santosh Chokhani <[email-masked]>
wrote:

> 1.  You are requiring the extension to be critical.  This may cause 
> denial of service during the transition stage while the application 
> implement the processing logic.  May be start with RECOMMENDED to be 
> critical and then transition to SHALL be critical when there is wider 
> support for the extension.

I thought about this.  The logic that was used in the past was that the
constraints can be ignored if they are not critical.  I'm not sure which is
worse.

> 2.  The language at the end of Section 2 regarding extension 
> processing and tying it to criticality does not seem right to me.  
> Criticality of extension should not impact its processing  It also 
> relates to my concerns regarding wrap up procedure in Section 3.  I would
like the criticality part removed.

This seems like the same as comment 1.
[Santosh] It is a bit different.  The I-D says "Conforming applications MUST
be able to process this extension.  If
   any CA certificate in the certification path includes an EKU constraints
extension that is marked as critical, and the end-entity
   certificate includes an extended key usage certificate extension,
   then the application MUST either process the EKU constraint or reject
   the certificate."  I would say even if the extension is marked
non-critical and end-entity certificate includes EKU, it needs to be
processed.  We do not generally change the processing semantics of an
extension due to criticality.  If what you are saying is that if the end
certificate does not include EKU and the application does not understand the
EKU constraints extension, it can be ignored.  But, that is dangerous since
the application will think the certificate is good for all key purposes and
the path is not.  Also, this will be impacted by the decision on whether you
choose input as Jim Schaad has suggested.  In that scenario, the extension
does need to be processed even if the end certificate does not have EKU.

> 3.  Now to the wrap up procedure in Section 3, I would recommend 
> taking an intersection of permitted EKU Constraint State and EKU in 
> the end certificate and then deleting the EKUs in the result that are 
> in the excluded EKU Constraint State.  Now, the resulting EKU set 
> should be returned to the application for enforcement.  It is quite 
> possible that some applications do not care about EKUs at all.  I 
> could live with if the group decides if the resulting EKU set is null, it
is a path validation failure.
> But, my preference is for the application to enforce it.

As I said in my response to Jim, I was trying to not impact the API to the
certification path validation library.  This would be a significant change.
It would trim the set if key purpose ids in the end-entity certificate to
those that meet the restrictions.  It is easy to add to the specification,
but it is harder to get deployed in applications.
[Santosh] The way the current logic is, if the path is not good for all the
EKUs in the end certificate, the path is invalid.  That may be ok for
Enterprise PKI and does reject mis-issued certificates assuming the
Enterprise PKI designer has done static analysis on EKU constraint required
at each stage.  But, this does not help the cross-certified environment.
Say one PKI wants to trust another for client authentication and S/MIME, but
not for Smart Card Logon.  The proposed approach will not work unless the
end certificate are issued for single key purpose.

[Santosh] The input approach suggested is less complicated that the approach
I suggest.  Under my approach, there is a possibility that you will need to
output a flag with the EKUs whether the list is excluded or not since there
is an edge case where only excluded get accumulated.

What do others think?
[Santosh] I have spoken as someone who designs lots of PKI stuff.  It would
be nice to hear from those who implement path validation libraries and
develop PK enabled applications as to what they prefer.  The proposed
approach of hard failure of a perfectly valid certificate which is good for
the key purpose the application desires is wrong.

Russ

---

From: "Santosh Chokhani" <[email-masked]>
Date: Tue, 17 May 2016 09:29:21 -0400

Hi Russ,

Regardless, the path validation logic needs to handle anyExtendedKeyUsage.

anyExtendedKeyUsage appearing in permitted does not make sense since the
field can be simply omitted.

anyExtendedKeyUsag appearing in excluded may make sense if you want the path
to be not valid for any specific EKU.

-----Original Message-----
From: Russ Housley [mailto:[email-masked]] 
Sent: Monday, May 16, 2016 5:14 PM
To: Santosh Chokhani <[email-masked]>
Cc: [email-masked]
Subject: Re: [Spasm] My take on handling EKU constraints

Santosh:

> The I-D should address anyExtendedKeyUsage.  Either it should be 
> prohibited from the permitted or excluded or the path validation 
> engine should treat this value in either field as the UNIVERSAL set.

I'd prefer to treat anyPurpose just like every other OID as far as the
constraints are concerned.

What do others think?

Russ

---

From: "Santosh Chokhani" <[email-masked]>
Date: Tue, 17 May 2016 09:32:22 -0400

Hi Russ,

I would add something to the effect "CAs asserting this extension SHOULD
consider including  OCSPSigning in permitted EKUs if the downstream CAs may
issue delegated OCSP Responder certificates"

-----Original Message-----
From: Russ Housley [mailto:[email-masked]] 
Sent: Monday, May 16, 2016 5:17 PM
To: Santosh Chokhani <[email-masked]>
Cc: [email-masked]
Subject: Re: [Spasm] My take on handling EKU constraints

> Delegated OCSP trust model will be useful.  May be in Security 

We could add a discussion about the consequences of a particular EKU in the
end-entity certificate, but I cannot see why that is needed here.  You seem
to be thinking about some specific concern, please say more.

Russ

---

From: "Santosh Chokhani" <[email-masked]>
Date: Tue, 17 May 2016 09:34:23 -0400

Sean,

I support your idea of making this a CHOICE.

Separately, upon further reflection and thought, having two state variables
in path processing logic may be simpler.  When I started working it in my
head, there are more edge cases if you tried only one variable leading to
more software complexity.

From: Spasm [mailto:[email-masked]] On Behalf Of Sean Leonard
Sent: Monday, May 16, 2016 11:56 PM
To: [email-masked]
Subject: Re: [Spasm] My take on handling EKU constraints

On May 16, 2016, at 2:16 AM, Sean Leonard  <mailto:[email-masked]>
<[email-masked]> wrote:

Hello:

 

The text does, but not the ASN.1. I.e., an ASN.1 compiler can't enforce the
constraint as written in the text. I see that as a flaw.

No, the text says that if the key purpose is the the excluded set, then it
is excluded.

I see how what I wrote could be misinterpreted; sorry about that. Of course
if the key purpose is in the excluded set, then it is excluded. In that
sense, an excluded OID takes precedence over the same OID being in the
permitted set.

The point is that putting an OID on both lists is pointless and needlessly
complicated. If an OID is on the permitted list AND the excluded list, then,
why is it on either list at all?

The permitted set of OIDs can, apparently, be: "infinity" (unbounded),
"nonzero" (finite: bounded to only those listed), or "none" (zero). The
moment ANY certificate in the path mentions a permitted set, you are forever
thrown out of "infinity". It is now finite. Possibly zero. So the effect of
having further excluded sets (after introducing the first permitted set), is
only to whittle away at the finite permitted set of OIDs. You may as well
either repeat the list of permitted EKUs, or whittle it down in the next
certificate in the chain. Mentioning excluded sets only makes sense at the
top of the chain, before the first "permitted set" is introduced.

Example: consider a single CA cert in the chain that mentions both permitted
and excluded:
{
permitted:
1.1.1.1
1.1.1.2

excluded:
1.1.1.2
1.1.1.3
1.1.1.4
}

If only 1.1.1.1 and 1.1.1.2 are permitted, then mentioning 1.1.1.3 and
1.1.1.4 as "excluded" serves no purpose. You may as well drop 1.1.1.3 and
1.1.1.4. Furthermore, since 1.1.1.2 is excluded, why bother mentioning it in
"permitted"? That likewise serves no purpose. You may as well have said:

{
permitted:
1.1.1.1
}

Mentioning the excluded set at all, only makes sense when there is no
defined permitted set (i.e., the permitted set is the "special value that
represents the universal set"). In that way, excluding those OIDs basically
means we have the universal set ("infinity") MINUS a few mentioned OIDs.

That is why I am (increasingly) harping on making this extension a CHOICE,
rather than a SEQUENCE that can permit both.

Sean

---

From: "Santosh Chokhani" <[email-masked]>
Date: Tue, 17 May 2016 09:37:58 -0400

Sean,

I think I know how Microsoft handles EKU.  But, can you confirm if CAPI
rejects  an end certificate if it does not have all the EKUs from the funnel
up to that point.

My experience is NO, but I have not tested it.

Unless I read the I-D and proposed changes discussed on this thread, the
proposal seems to be that if the end certificate does not have all the
permitted and does not have any of the excluded, the certificate is
rejected.  That seems quite harsh and unnecessary.

-----Original Message-----
From: Spasm [mailto:[email-masked]] On Behalf Of Sean Leonard
Sent: Tuesday, May 17, 2016 12:22 AM
To: [email-masked]
Subject: [Spasm] Maybe just do permitted constraints only Re: My take on
handling EKU constraints

On 5/16/2016 7:01 AM, Stephen Farrell wrote:
> [...]
> I hope we all agree that this kind of thing ought be mostly driven by 
> what those implementing or deploying certificate validation and 
> applications want and are willing to do and what they think makes 
> sense in terms of APIs etc. For example, I wondered which 
> application(s) you are involved in developing you meant in the above.
>
> One thing I think we need to be quite careful about with all of this 
> planned work is to not repeat mistakes we (incl. me) made in the past 
> where we designed a bunch of PKI machinery that didn't get used, or 
> that made it harder to use PKI, or that made PKI less useful.
I really want to channel Stephen here on this point about avoiding making
algorithms too complicated, that people won't use.

Sure it is possible to write algorithms that do all this "intersectionality"
and "differential" stuff with permitted and excluded items. But maybe it
doesn't make real-world sense (as we have seen with lackluster support for
Name Constraints).

Taking a step back, I question the need for the excluded set. By default, a
trust anchor that is defined purely by a certificate (i.e., a self-signed,
self-issued one, one under the control of the trust anchor
party) will naturally "want" universal capabilities: it is more economically
valuable. Of course if I create a CA for my own purposes, I will imbue it
with universal trust. I wouldn't exclude myself from issuing certs for
specific applications.

The situation changes when the trust point delegates its authority to the
next guy down the line (aka, issues a certificate). I want to be sure that
the next guy doesn't abuse my universal authority, so I want to constrain
him/her/it. Therefore, I say: "you can do these enumerated things, but I'm
not giving you a blank check". Specifying an excluded set is tantamount to
writing an /almost/ blank check: "you can put any number in the amount
field, just as long as it's not one million, or four billion". Not a good
situation. Principle of least privilege, folks.

Now it is possible (in fact, quite likely) that a certificate-using
application will want to exclude purposes entirely from the path. Maybe the
user (or sysadmins) "trust" some CA for what it contractually claims to
limit itself to issue, but no matter what, the user is never going to
"trust" that CA for "Kernel Mode Signing". That exclusion is perfectly valid
(and perhaps can be specified in the path processing algorithm, especially
at the "top"), but is not part of the artifacts in the certification path
itself.

The way that I understand how the Microsoft EKU implementation works, is
that it's a funnel of permitted usages only. At the topmost level, the
user/application says exactly what EKUs it will allow the trust anchor to
promulgate: everything ("Enable all purposes for this certificate"), nothing
("Disable all purposes for this certificate"), or exactly a finite list of
specific things ("Enable only the following purposes: 
[OIDs]"). At each step in the certification path, the cert can contract the
set of usages, but cannot expand them. What is effective at the end-entity
certificate is just the intersection of all permitted usages. 
The dialog box says: "Note: you may only edit the certificate purposes that
are allowed by the certification path."

We can make things a lot simpler if we make this EKU Constraints extension
just be a list of permittedKeyPurposeIds, in which case, it would be
syntactically identical to ExtKeyUsageSyntax.

I would also posit that Name Constraints would be a lot easier to implement,
and a lot more useful, if they were defined as "permitted" 
only, for analogous reasons.

(I have no comment or insight on certificate policies, other than, a lot of
people find them awfully complicated.)

Sean

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 17 May 2016 14:48:09 +0100

Question for the list:

On 17/05/16 14:26, Santosh Chokhani wrote:
>  But, this does not help the cross-certified environment.

Is that environment of interest? Should we de-scope it in the
proposed charter? Or if not, should it be limited to consideration
for only the smime email application?

From what I've heard so far, the only folks who seem to be
planning implementations are interested in the WebPKI and
in enterprise smime. Is that correct?

If in fact we have implementers who are planning to write code
for something else, those implementers should say so before
we're done with the charter.

We may save ourselves some extended debates if we can craft
charter text to reflect the scope of the real work that folks
want to do.

<SponsoringADHatOn>

In any case, this mail thread has convinced me that we
do need some more scoping text in the charter, perhaps to
name a primary use-case for each of the work items and to
say that wider (abstract, near theoretical) considerations
of (the consequences of) the same work items are to be
discouraged as we know from history that those discussions
move glacially, are terribly distracting and have lead to
worse outcomes in the past. Text suggestions welcome.

And to be clear, I will not be pushing the next button in
the formal chartering process until we've tackled this
issue, either adding text such as the above or convincing
me that it's not needed. (And I fully admit to possibly
having an overly-sensitive ocean-boiling-ahead detector
here;-)

</SponsoringADHatOn>

Cheers,
S.

---

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

> That is why I am (increasingly) harping on making this extension a CHOICE, rather than a SEQUENCE that can permit both.

What do others think?

Russ

---

From: "Jim Schaad" <[email-masked]>
Date: Tue, 17 May 2016 08:57:03 -0700

The ASN.1 you are looking for is

   NameConstraints ::= SEQUENCE {

        permittedSubtrees       [0] GeneralSubtrees OPTIONAL,

        excludedSubtrees        [1] GeneralSubtrees OPTIONAL

   }

   (WITH COMPONENTS { ..., permittedSubtrees PRESENT} |

    WITH COMPONENTS { ..., excludedSubtrees PRESENT }}

Which formally requires one of the elements to be present.

Jim

From: Spasm [mailto:[email-masked]] On Behalf Of Sean Leonard
Sent: Monday, May 16, 2016 8:56 PM
To: [email-masked]
Subject: Re: [Spasm] My take on handling EKU constraints

Hello:

 

 

excluded:
1.1.1.2
1.1.1.3
1.1.1.4
}

{
permitted:
1.1.1.1
}

Sean

---

From: Russ Housley <[email-masked]>
Date: Tue, 17 May 2016 12:02:45 -0400

> The text already says that.

I think that we can use some modern ASN.1 features to say that one, the other, or both must be present.

EKUConstraints ::= SEQUENCE {
  permittedKeyPurposeIds   [0] KeyPurposeIds OPTIONAL,
  excludedKeyPurposeIds    [1] KeyPurposeIds OPTIONAL }
  ( WITH COMPONENTS { ...,
      permittedKeyPurposeIds   PRESENT,
      excludedKeyPurposeIds    PRESENT } |
    WITH COMPONENTS { ...,
      permittedKeyPurposeIds   PRESENT,
      excludedKeyPurposeIds    ABSENT } |
    WITH COMPONENTS { ...,
      permittedKeyPurposeIds   ABSENT,
      excludedKeyPurposeIds    PRESENT } )

I have not double checked this with a compiler yet, but I’, pretty sure that this provides the capability you were talking about.

Russ

---

From: "Brown, Wendy (10421)" <[email-masked]>
Date: Tue, 17 May 2016 16:18:26 +0000

Please do NOT de-scope the cross-certified environment.
Proposed changes of this type may have a great impact on the US Federal PKI which is a large cross-certified environment.

Thanks,
Wendy Brown

-----Original Message-----
From: Stephen Farrell [mailto:[email-masked]]
Sent: Tuesday, May 17, 2016 9:48 AM
To: [email-masked]
Subject: [Spasm] more scoping is needed (was: Re: My take on handling EKU constraints)

Question for the list:

<SponsoringADHatOn>

</SponsoringADHatOn>

Cheers,
S.

NOTICE: Protiviti is a global consulting and internal audit firm composed of experts specializing in risk and advisory services. Protiviti is not licensed or registered as a public accounting firm and does not issue opinions on financial statements or offer attestation services. This electronic mail message is intended exclusively for the individual or entity to which it is addressed. This message, together with any attachment, may contain confidential and privileged information. Any views, opinions or conclusions expressed in this message are those of the individual sender and do not necessarily reflect the views of Protiviti Inc. or its affiliates. Any unauthorized review, use, printing, copying, retention, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email message to the sender and delete all copies of this message. Thank you.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 17 May 2016 17:28:13 +0100

Hiya,

On 17/05/16 17:18, Brown, Wendy (10421) wrote:
> Please do NOT de-scope the cross-certified environment. Proposed
> changes of this type may have a great impact on the US Federal PKI
> which is a large cross-certified environment.

So I get that concern. Mine however is that we have a
history of the complexity inherent in that particular
PKI causing unnecessary complexity elsewhere, e.g. for
the WebPKI, where things like policy mappings are of
no use whatsoever.

To be entirely clear: I have no interest in sponsoring
anything where there's a reasonable chance of it turning
into another 19 year long odyssey involving many debates
about PKI-angels on the heads of PKI-pins.

Having to consider all the complexity of the US Federal
PKI when any other change is suggested sounds to me to
be perilously close to the above, so I would welcome
folks' suggested charter text on how we can handle that
conundrum.

S.

> 
> Thanks, Wendy Brown
> 
> -----Original Message----- From: Stephen Farrell
> [mailto:[email-masked]] Sent: Tuesday, May 17, 2016 9:48
> AM To: [email-masked] Subject: [Spasm] more scoping is needed (was:
> Re: My take on handling EKU constraints)
> 
> 
> Question for the list:
> 
> planning implementations are interested in the WebPKI and in
> enterprise smime. Is that correct?
> 
> If in fact we have implementers who are planning to write code for
> something else, those implementers should say so before we're done
> with the charter.
> 
> We may save ourselves some extended debates if we can craft charter
> text to reflect the scope of the real work that folks want to do.
> 
> <SponsoringADHatOn>
> 
> In any case, this mail thread has convinced me that we do need some
> more scoping text in the charter, perhaps to name a primary use-case
> for each of the work items and to say that wider (abstract, near
> theoretical) considerations of (the consequences of) the same work
> items are to be discouraged as we know from history that those
> discussions move glacially, are terribly distracting and have lead
> to worse outcomes in the past. Text suggestions welcome.
> 
> And to be clear, I will not be pushing the next button in the formal
> chartering process until we've tackled this issue, either adding text
> such as the above or convincing me that it's not needed. (And I fully
> admit to possibly having an overly-sensitive ocean-boiling-ahead
> detector here;-)
> 
> </SponsoringADHatOn>
> 
> Cheers, S.
> 
> NOTICE: Protiviti is a global consulting and internal audit firm
> composed of experts specializing in risk and advisory services.
> Protiviti is not licensed or registered as a public accounting firm
> and does not issue opinions on financial statements or offer
> attestation services. This electronic mail message is intended
> exclusively for the individual or entity to which it is addressed.
> This message, together with any attachment, may contain confidential
> and privileged information. Any views, opinions or conclusions
> expressed in this message are those of the individual sender and do
> not necessarily reflect the views of Protiviti Inc. or its
> affiliates. Any unauthorized review, use, printing, copying,
> retention, disclosure or distribution is strictly prohibited. If you
> have received this message in error, please immediately advise the
> sender by reply email message to the sender and delete all copies of
> this message. Thank you. 
> _______________________________________________ Spasm mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/spasm
>

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 17 May 2016 16:31:01 +0000

> Having to consider all the complexity of the US Federal PKI when any other
> change is suggested sounds to me to be perilously close to the above, so I
> would welcome folks' suggested charter text on how we can handle that
> conundrum.

I think the FedPKI can find a WG within their org to profile the IETF stuff.

Federated PKI's should be out of scope here.

---

From: "Jim Schaad" <[email-masked]>
Date: Tue, 17 May 2016 10:07:43 -0700

I can see two different types of statements coming from this:

1.  We are not going to pick up any work which is not specific to environments other than WebPKI and S/MIME.  (For some value of WebPKI), and

2. We are going to ignore any implications of our work which are not in those two environments.

I am assuming you mean the first statement not the second in terms of doing scoping.

Jim

-----Original Message-----
From: Spasm [mailto:[email-masked]] On Behalf Of Stephen Farrell
Sent: Tuesday, May 17, 2016 9:28 AM
To: Brown, Wendy (10421) <[email-masked]>; [email-masked]
Subject: Re: [Spasm] more scoping is needed

Hiya,

> which is a large cross-certified environment.

So I get that concern. Mine however is that we have a history of the complexity inherent in that particular PKI causing unnecessary complexity elsewhere, e.g. for the WebPKI, where things like policy mappings are of no use whatsoever.

To be entirely clear: I have no interest in sponsoring anything where there's a reasonable chance of it turning into another 19 year long odyssey involving many debates about PKI-angels on the heads of PKI-pins.

Having to consider all the complexity of the US Federal PKI when any other change is suggested sounds to me to be perilously close to the above, so I would welcome folks' suggested charter text on how we can handle that conundrum.

S.

> [mailto:[email-masked]] Sent: Tuesday, May 17, 2016 9:48 AM 
> To: [email-masked] Subject: [Spasm] more scoping is needed (was:
> Is that environment of interest? Should we de-scope it in the proposed 
> charter? Or if not, should it be limited to consideration for only the 
> smime email application?
> 
> discussions move glacially, are terribly distracting and have lead to 
> not necessarily reflect the views of Protiviti Inc. or its affiliates. 
> Any unauthorized review, use, printing, copying, retention, disclosure 
> or distribution is strictly prohibited. If you have received this 
> message in error, please immediately advise the sender by reply email 
> message to the sender and delete all copies of this message. Thank 
> you.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 17 May 2016 19:44:38 +0100

On 17/05/16 18:07, Jim Schaad wrote:
> 1.  We are not going to pick up any work which is not specific to
> environments other than WebPKI and S/MIME.  (For some value of
> WebPKI), and
> 

Not quite.

I do sort of agree with #1. Or at least the work items identified so
far seem to fit that description. (Hence my suggestion to tie any
more precise scoping to the specific work items.)

Wrt #2 with s/ignore any/not endlessly debate and get side-tracked by
the/ then I'd agree. I'd love something in the charter that allows
the chairs to beat away such debate, given that it's probably quite
likely folks will want to engage in such. And I base that on having
been involved and watched us (incl. me) do that back since the start
of PKIX in 1995;-)

S.

> 
> Jim
> 
> 
> -----Original Message----- From: Spasm
> [mailto:[email-masked]] On Behalf Of Stephen Farrell Sent:
> Tuesday, May 17, 2016 9:28 AM To: Brown, Wendy (10421)
> <[email-masked]>; [email-masked] Subject: Re: [Spasm] more
> scoping is needed
> 
> 
> Hiya,
> 
> So I get that concern. Mine however is that we have a history of the
> complexity inherent in that particular PKI causing unnecessary
> complexity elsewhere, e.g. for the WebPKI, where things like policy
> mappings are of no use whatsoever.
> 
> To be entirely clear: I have no interest in sponsoring anything where
> there's a reasonable chance of it turning into another 19 year long
> odyssey involving many debates about PKI-angels on the heads of
> PKI-pins.
> 
> Having to consider all the complexity of the US Federal PKI when any
> other change is suggested sounds to me to be perilously close to the
> above, so I would welcome folks' suggested charter text on how we can
> handle that conundrum.
> 
> S.
> 
>> 
>> Thanks, Wendy Brown
>> 
>> AM To: [email-masked] Subject: [Spasm] more scoping is needed
>> (was: Re: My take on handling EKU constraints)
>> 
>> 
>> Question for the list:
>> 
>>  more scoping text in the charter, perhaps to name a primary
>> use-case for each of the work items and to say that wider
>> (abstract, near theoretical) considerations of (the consequences
>> of) the same work items are to be discouraged as we know from
>> history that those discussions move glacially, are terribly
>> distracting and have lead to worse outcomes in the past. Text
>> suggestions welcome.
>> 
>> And to be clear, I will not be pushing the next button in the
>> formal chartering process until we've tackled this issue, either
>> adding text such as the above or convincing me that it's not
>> needed. (And I fully admit to possibly having an overly-sensitive
>> ocean-boiling-ahead detector here;-)
>> 
>> </SponsoringADHatOn>
>> 
>> Cheers, S.
>> 
>> This message, together with any attachment, may contain
>> confidential and privileged information. Any views, opinions or
>> conclusions expressed in this message are those of the individual
>> sender and do not necessarily reflect the views of Protiviti Inc.
>> or its affiliates. Any unauthorized review, use, printing, copying,
>> retention, disclosure or distribution is strictly prohibited. If
>> you have received this message in error, please immediately advise
>> the sender by reply email message to the sender and delete all
>> copies of this message. Thank you.

---

From: Russ Housley <[email-masked]>
Date: Tue, 17 May 2016 14:30:51 -0400

Santosh:

Breaking into two responses, each with a different subject line.

> does need to be processed even if the end certificate does not have EKU.

We have had this discussion over and over on the PKIX mail list.

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.

Russ

---

From: Russ Housley <[email-masked]>
Date: Tue, 17 May 2016 15:18:04 -0400

Santosh:

> is an edge case where only excluded get accumulated.

Jim has suggested that it would be good to change Section 3.1 to provide an input that gives a set of key purpose identifiers that are desired.

You suggested that it would be good to change Section 3.6 to provide an output that provides a trimmed set of key purpose identifiers that are authorized.

I understand the reason that these are desired.  My concern with these ideas is that the API to the certification path library is impacted.  It seems to me that we can meet the CAB Forum need without these.  I do not want to add a hurdle to the deployment.

> the key purpose the application desires is wrong.

Indeed.  Changing the API had a significant impact to both.

Russ

[1]

---

From: Russ Housley <[email-masked]>
Date: Tue, 17 May 2016 15:28:33 -0400

Regarding anyExtendedKeyUsage, RFC 5280 says:

   If a CA includes extended key usages to satisfy such applications,
   but does not wish to restrict usages of the key, the CA can include
   the special KeyPurposeId anyExtendedKeyUsage in addition to the
   particular key purposes required by the applications.  Conforming CAs
   SHOULD NOT mark this extension as critical if the anyExtendedKeyUsage
   KeyPurposeId is present.  Applications that require the presence of a
   particular purpose MAY reject certificates that include the
   anyExtendedKeyUsage OID but not the particular OID expected for the
   application.

So, I propose:

   The special key purpose identifier anyExtendedKeyUsage is not treated
   differently than any other key purpose identifier in processing the
   constraints.  If the anyExtendedKeyUsage key purpose identifier
   matches an entry in the excludedKeyPurposeIds field, then the
   anyExtendedKeyUsage key purpose identifier MUST NOT appear in the
   extended key usage extension of the end-entity certificate.  If the
   anyExtendedKeyUsage key purpose identifier appears in the extended
   key usage extension of the end-entity certificate, then the
   anyExtendedKeyUsage key purpose identifier MUST in the
   permittedKeyPurposeIds field.

Russ

---

From: Russ Housley <[email-masked]>
Date: Tue, 17 May 2016 15:34:27 -0400

Santosh:

Okay.  I suggest:

   5.  Security Considerations

   When a CA includes the extended key usage constraints certificate
   extension for a subordinate CA, the OCSPSigning key purpose
   identifier SHOULD be included in the permittedKeyPurposeIds field to
   enable the issuance of delegated OCSP Responder certificates.

Russ

---

From: Russ Housley <[email-masked]>
Date: Tue, 17 May 2016 15:51:16 -0400

Santosh and Sean are speaking for CHOICE instead of SEQUENCE.

The resulting ASN.1 would be:

   ext-ExtKeyUsageConstraints EXTENSION ::= {
       SYNTAX EKUConstraints
       IDENTIFIED BY id-ce-ekuConstraints }

   id-ce-ekuConstraints OBJECT IDENTIFIER ::=  { id-pe TBD }

   EKUConstraints ::= CHOICE {
       permittedKeyPurposeIds   [0] KeyPurposeIds,
       excludedKeyPurposeIds    [1] KeyPurposeIds }

   KeyPurposeIds ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId

Does anyone think that this is the wrong thing to do?

Can you think of a case where a CA might want to use a combination of the two in the same certificate?

Russ

On May 17, 2016, at 9:34 AM, Santosh Chokhani <[email-masked]> wrote:

> Separately, upon further reflection and thought, having two state variables in path processing logic may be simpler.  When I started working it in my head, there are more edge cases if you tried only one variable leading to more software complexity.
>  
> [SNIP]

---

From: Russ Housley <[email-masked]>
Date: Tue, 17 May 2016 15:59:40 -0400

This is a better way to do it than the way that I posted ….

It is not needed if we change the SEQUENCE to a CHOICE.

Russ

On May 17, 2016, at 11:57 AM, Jim Schaad <[email-masked]> wrote:

> The text does, but not the ASN.1. I.e., an ASN.1 compiler can't enforce the constraint as written in the text. I see that as a flaw.
> 
> 
>  
>  
> I see how what I wrote could be misinterpreted; sorry about that. Of course if the key purpose is in the excluded set, then it is excluded. In that sense, an excluded OID takes precedence over the same OID being in the permitted set.
> 
> The point is that putting an OID on both lists is pointless and needlessly complicated. If an OID is on the permitted list AND the excluded list, then, why is it on either list at all?
> 
> The permitted set of OIDs can, apparently, be: "infinity" (unbounded), "nonzero" (finite: bounded to only those listed), or "none" (zero). The moment ANY certificate in the path mentions a permitted set, you are forever thrown out of "infinity". It is now finite. Possibly zero. So the effect of having further excluded sets (after introducing the first permitted set), is only to whittle away at the finite permitted set of OIDs. You may as well either repeat the list of permitted EKUs, or whittle it down in the next certificate in the chain. Mentioning excluded sets only makes sense at the top of the chain, before the first "permitted set" is introduced.
> 
> Example: consider a single CA cert in the chain that mentions both permitted and excluded:
> {
> permitted:
> 1.1.1.1
> 1.1.1.2
> 
> excluded:
> 1.1.1.2
> 1.1.1.3
> 1.1.1.4
> }
> 
> If only 1.1.1.1 and 1.1.1.2 are permitted, then mentioning 1.1.1.3 and 1.1.1.4 as "excluded" serves no purpose. You may as well drop 1.1.1.3 and 1.1.1.4. Furthermore, since 1.1.1.2 is excluded, why bother mentioning it in "permitted"? That likewise serves no purpose. You may as well have said:
> 
> {
> permitted:
> 1.1.1.1
> }
> 
> Mentioning the excluded set at all, only makes sense when there is no defined permitted set (i.e., the permitted set is the "special value that represents the universal set"). In that way, excluding those OIDs basically means we have the universal set ("infinity") MINUS a few mentioned OIDs.
>

---

From: "Jim Schaad" <[email-masked]>
Date: Tue, 17 May 2016 13:22:42 -0700

Given the recent suggested change, I think that one might wish to say

  Permit = S/MIME,

  Exclude = anyKeyUsage

One would need to remove the any usage if one really wants to restrict to a
specific usage.

Jim

From: Spasm [mailto:[email-masked]] On Behalf Of Russ Housley
Sent: Tuesday, May 17, 2016 12:51 PM
To: Santosh Chokhani <[email-masked]>; Sean Leonard
<[email-masked]>
Cc: [email-masked]
Subject: Re: [Spasm] My take on handling EKU constraints

       SYNTAX EKUConstraints

 

Can you think of a case where a CA might want to use a combination of the
two in the same certificate?

Russ

On May 17, 2016, at 9:34 AM, Santosh Chokhani <[email-masked]
<mailto:[email-masked]> > wrote:

Sean,

From: Spasm [ <mailto:[email-masked]> mailto:[email-masked]]
On Behalf Of Sean Leonard
Sent: Monday, May 16, 2016 11:56 PM
To:  <mailto:[email-masked]> [email-masked]
Subject: Re: [Spasm] My take on handling EKU constraints

[SNIP]

Sean

---

From: Sean Turner <[email-masked]>
Date: Tue, 17 May 2016 16:24:54 -0400

>> That is why I am (increasingly) harping on making this extension a CHOICE, rather than a SEQUENCE that can permit both.

I tend to lean towards SEQUENCE.

spt

---

From: "Santosh Chokhani" <[email-masked]>
Date: Wed, 18 May 2016 08:36:27 -0400

Hi Steve,

It would be nice if the I-D addressed the purpose of the extension and limitations on its scope and the problem being solved by the path validation logic.

Then we can either debate the scope or make the I-D accurate with respect to agreed on scope.

-----Original Message-----
From: Spasm [mailto:[email-masked]] On Behalf Of Stephen Farrell
Sent: Tuesday, May 17, 2016 9:48 AM
To: [email-masked]
Subject: [Spasm] more scoping is needed (was: Re: My take on handling EKU constraints)

Question for the list:

>  But, this does not help the cross-certified environment.

Is that environment of interest? Should we de-scope it in the proposed charter? Or if not, should it be limited to consideration for only the smime email application?

>From what I've heard so far, the only folks who seem to be planning implementations are interested in the WebPKI and in enterprise smime. Is that correct?

If in fact we have implementers who are planning to write code for something else, those implementers should say so before we're done with the charter.

We may save ourselves some extended debates if we can craft charter text to reflect the scope of the real work that folks want to do.

<SponsoringADHatOn>

In any case, this mail thread has convinced me that we do need some more scoping text in the charter, perhaps to name a primary use-case for each of the work items and to say that wider (abstract, near theoretical) considerations of (the consequences of) the same work items are to be discouraged as we know from history that those discussions move glacially, are terribly distracting and have lead to worse outcomes in the past. Text suggestions welcome.

And to be clear, I will not be pushing the next button in the formal chartering process until we've tackled this issue, either adding text such as the above or convincing me that it's not needed. (And I fully admit to possibly having an overly-sensitive ocean-boiling-ahead detector
here;-)

</SponsoringADHatOn>

Cheers,
S.

---

From: Carl Wallace <[email-masked]>
Date: Wed, 18 May 2016 09:03:14 -0400

>more precise scoping to the specific work items.)

If doing S/MIME, aren't some of the constraints pruned off for the WebPKI
applicable (i.e., some of what is used in the US Fed PKI)? There are a
fair number of certs issued to people hanging off the "WebPKI" too.
Perhaps at a minimum we need a means of disallowing that practice entirely
if concerns related to S/MIME, etc. certs are to be shunted off elsewhere.

<snip>

---

From: Carl Wallace <[email-masked]>
Date: Wed, 18 May 2016 09:08:40 -0400

>making algorithms too complicated, that people won't use.

I thought part of the problem being addressed was aligning with how
implementers used EKU in ways different than 5280 defined. Are those
practices documented anywhere and do they align well with this I-D? If we
are defining a new EKU mechanism that does not align with the practices we
aren't much better off unless there is commitment by the implementers who
diverged from 5280 to adopt the new spec.

Sorry if this is a repeat question. This thread has many parts I've not
yet read.

<snip>

---

From: "Santosh Chokhani" <[email-masked]>
Date: Wed, 18 May 2016 09:27:21 -0400

Hi Russ,

Your response related to criticality assertion.  My question is related to
processing and the quoted text in the I-D "Conforming applications MUST be
able to process this extension.  If
any CA certificate in the certification path includes an EKU constraints
extension that is marked as critical, and the end-entity certificate
includes an extended key usage certificate extension, then the application
MUST either process the EKU constraint or reject  the certificate."  

I wonder if this could be misconstrued what to do when the extension is not
marked critical since application that recognizes the extension MUST process
it regardless of criticality.  

-----Original Message-----
From: Russ Housley [mailto:[email-masked]] 
Sent: Tuesday, May 17, 2016 2:31 PM
To: Santosh Chokhani <[email-masked]>
Cc: [email-masked]
Subject: Criticality of EKU constraints

Santosh:

> [Santosh] It is a bit different.  The I-D says "Conforming 
> applications MUST be able to process this extension.  If
>   any CA certificate in the certification path includes an EKU 
> constraints extension that is marked as critical, and the end-entity
> extension due to criticality.  If what you are saying is that if the 
> end certificate does not include EKU and the application does not 
> understand the EKU constraints extension, it can be ignored.  But, 
> that is dangerous since the application will think the certificate is 
> good for all key purposes and the path is not.  Also, this will be 
> impacted by the decision on whether you choose input as Jim Schaad has 
> suggested.  In that scenario, the extension does need to be processed even
if the end certificate does not have EKU.

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:

     Conforming CAs MUST mark this extension as critical .

Russ

---

From: "Santosh Chokhani" <[email-masked]>
Date: Wed, 18 May 2016 09:38:21 -0400

Hi Russ,

As I said to Steve in another thread, once the I-D identifies the objective
for path validation engine, we can determine if the proposed logic meets the
objective.

So I would like to know the objective/purpose.

In the meantime, can you confirm that I am reading and processing the I-D
correctly.  And that is, there is hard path validation failure if the any of
the EKU in the end certificate appears on the excluded end state and does
not appear on the permitted end state.

-----Original Message-----
From: Russ Housley [mailto:[email-masked]] 
Sent: Tuesday, May 17, 2016 3:18 PM
To: Santosh Chokhani <[email-masked]>
Cc: [email-masked]
Subject: Output from EKU constraints

Santosh:

> As I said in my response to Jim, I was trying to not impact the API to 
> the certification path validation library.  This would be a significant
change.
> It would trim the set if key purpose ids in the end-entity certificate 
> to those that meet the restrictions.  It is easy to add to the 
> specification, but it is harder to get deployed in applications.
> [Santosh] The way the current logic is, if the path is not good for 
> all the EKUs in the end certificate, the path is invalid.  That may be 
> ok for Enterprise PKI and does reject mis-issued certificates assuming 
> the Enterprise PKI designer has done static analysis on EKU constraint 
> required at each stage.  But, this does not help the cross-certified
environment.
> Say one PKI wants to trust another for client authentication and 
> S/MIME, but not for Smart Card Logon.  The proposed approach will not 
> work unless the end certificate are issued for single key purpose.
> 
> [Santosh] The input approach suggested is less complicated that the 
> approach I suggest.  Under my approach, there is a possibility that 
> you will need to output a flag with the EKUs whether the list is 
> excluded or not since there is an edge case where only excluded get
accumulated.

Jim has suggested that it would be good to change Section 3.1 to provide an
input that gives a set of key purpose identifiers that are desired.

You suggested that it would be good to change Section 3.6 to provide an
output that provides a trimmed set of key purpose identifiers that are
authorized.

I understand the reason that these are desired.  My concern with these ideas
is that the API to the certification path library is impacted.  It seems to
me that we can meet the CAB Forum need without these.  I do not want to add
a hurdle to the deployment.

> What do others think?
> [Santosh] I have spoken as someone who designs lots of PKI stuff.  It 
> would be nice to hear from those who implement path validation 
> libraries and develop PK enabled applications as to what they prefer.  
> The proposed approach of hard failure of a perfectly valid certificate 
> which is good for the key purpose the application desires is wrong.

Russ

[1]

---

From: Carl Wallace <[email-masked]>
Date: Wed, 18 May 2016 09:47:17 -0400

On 5/17/16, 12:31 PM, "Spasm on behalf of Salz, Rich"
<[email-masked] on behalf of [email-masked]> wrote:

>>other

A good deal of that complexity is working around implementer decisions and
difficulties applying constraints in the right places. The root problem is
poor constraint mechanisms.

>I think the FedPKI can find a WG within their org to profile the IETF

The "FedPKI" is also part of the "WebPKI". I suppose looking the other way
at the problems in that segment is one approach.

In any case, is it really a Fed PKI problem, or a user certificate
problem? If the latter, it's still an issue here for S/MIME. To cleanly
prune this off would require means of constraining Web PKI CAs to validate
web server certs only. Maybe the emerging EKU spec could constrain trust
anchors associated with web server certificate validation. We can't really
saw off one piece without constraining the other.

>Federated PKI's should be out of scope here.

"Federated" and "cross-certified" are ambiguous. It'd be better if the
extensions that you do not wish to support were simply listed.

---

From: "Santosh Chokhani" <[email-masked]>
Date: Wed, 18 May 2016 09:50:55 -0400

Hi Russ,

Thanks.  This incorporates my suggestion.

-----Original Message-----
From: Russ Housley [mailto:[email-masked]] 
Sent: Tuesday, May 17, 2016 3:34 PM
To: Santosh Chokhani <[email-masked]>
Cc: [email-masked]
Subject: Re: [Spasm] My take on handling EKU constraints

Santosh:

Okay.  I suggest:

Russ

On May 17, 2016, at 9:32 AM, Santosh Chokhani <[email-masked]>
wrote:

> Hi Russ,
> 
> I would add something to the effect "CAs asserting this extension 
> SHOULD consider including  OCSPSigning in permitted EKUs if the 
> downstream CAs may issue delegated OCSP Responder certificates"
> 
> We could add a discussion about the consequences of a particular EKU 
> in the end-entity certificate, but I cannot see why that is needed 
> here.  You seem to be thinking about some specific concern, please say
more.

---

From: "Santosh Chokhani" <[email-masked]>
Date: Wed, 18 May 2016 09:50:55 -0400

Hi Russ,

Thanks.  Adding this language satisfies my concern.

I suggest you revise the last sentence as follows to fix the grammar and
ensure that it appears in all the fields in the path.  " If the
   anyExtendedKeyUsage key purpose identifier appears in the extended
   key usage extension of the end-entity certificate, then the
   anyExtendedKeyUsage key purpose identifier MUST appear in all the
   permittedKeyPurposeIds fields of the CA certificates in the path."

-----Original Message-----
From: Russ Housley [mailto:[email-masked]] 
Sent: Tuesday, May 17, 2016 3:29 PM
To: Santosh Chokhani <[email-masked]>
Cc: [email-masked]
Subject: Re: [Spasm] My take on handling EKU constraints

So, I propose:

Russ

On May 17, 2016, at 9:29 AM, Santosh Chokhani <[email-masked]>
wrote:

> anyExtendedKeyUsage appearing in permitted does not make sense since 
> the field can be simply omitted.
> 
> anyExtendedKeyUsag appearing in excluded may make sense if you want 
> the path to be not valid for any specific EKU.
>

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 18 May 2016 15:15:53 +0100

Hi Carl,

> poor constraint mechanisms.

I have to say that the above is not helping me feel more
confident that this proposed working group will keep to a
limited scope with tightly focused discussions.

If people on this list prefer a broadly scoped working
group to consider many potential issues with PKI then
that's fine, but is not something that I'm interested in
sponsoring. If people prefer to get some specific and
concrete bits of work done in a tightly scoped WG then
I am interested in sponsoring that.

I think I've made my concerns sufficiently clear at this
point so I'll be looking forward to seeing proposed OLD/NEW
changes to the charter text [1] that aims to help us tighten
up the scope of the proposed WG and that the chairs can use
to keep discussions out of the weeds.

It seems that (particularly) item #2 in the proposed
charter text [1] is what's tripping us up in that respect
so possible changes might be a) delete that item or b) add
a sentence about the intended scope for that work. But if
someone has other scope-tightening things to suggest please
do so.

Cheers,
S.

PS: I'm not sure if its visible to others, but as an AD I see
a big red button labelled "Abandon charter" at [1] and I'm
just fine with hitting that if we can't resolve this issue.

[1] https://datatracker.ietf.org/doc/charter-ietf-spasm/

---

From: Carl Wallace <[email-masked]>
Date: Wed, 18 May 2016 10:19:56 -0400

>I am interested in sponsoring that.

Note, I am not suggesting a "broadly scoped working group", rather I am
suggesting that setting the user certificate problem aside should be done
with a mechanism that enforces this exclusion.

---

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

Santosh:

Does this resolve your concern?

   Conforming CAs MUST mark this extension as critical, and conforming
   CAs MUST NOT issue certificates where this extension is an empty
   sequence.  That is, at least one of the permittedKeyPurposeIds field
   or the excludedKeyPurposeIds field MUST be present.

   Conforming applications MUST be able to process this extension.  If
   any CA certificate in the certification path includes an extended key
   usage constraints extension and the end-entity certificate includes
   an extended key usage certificate extension, then the application
   MUST either process the extended key usage extension constraint or
   reject the certificate.

Russ

---

From: Russ Housley <[email-masked]>
Date: Wed, 18 May 2016 10:31:09 -0400

Santosh:

Please see this message in the PKIX mail list archive:
https://mailarchive.ietf.org/arch/msg/pkix/MHwcSWuuzezj4qHuzSmbYeGUbdI

In my view, the technical solution that puts the EKU certificate extension in the intermediate CA certificate was not the best technical solution.  I’m proposing an alternative technical solution to the situation.

Russ

---

From: Russ Housley <[email-masked]>
Date: Wed, 18 May 2016 11:14:44 -0400

>   permittedKeyPurposeIds fields of the CA certificates in the path."

I’ll check the grammar, but your proposed text is not correct.  Upon reflection, the text I proposed is not right either.

The permitted_key_purpose_ids state variable starts with the universal set.  Then, as each certificate in the path is processed, the permittedKeyPurposeIds, when it is present, reduces the entries in the permitted_key_purpose_ids state variable.  It is assigned the intersection.  So, when the permittedKeyPurposeIds field is absent, the set is not reduced.  In fact, if the permittedKeyPurposeIds field never appears, it remains the universal set.

I suggest a re-write of several paragraphs in Section 2:

   Restrictions are defined in terms of permitted or excluded key
   purpose identifiers.

   The permitted key purpose identifiers begins with the universal set.
   Then, as each certificate in the certification path is processed, the
   permitted key purpose identifiers are reduced to the intersection of
   the previous set and the ones listed in the permittedKeyPurposeIds
   field.  Finally, each key purpose identifier in the extended key
   usage extension of the end-entity certificate MUST appear in the
   permitted key purpose identifiers set.

   The excluded key purpose identifiers begins with the empty set.
   Then, as each certificate in the certification path is processed, the
   excluded key purpose identifiers are increased to the union of the
   previous set and the ones listed in the excludedKeyPurposeIds field.
   Finally, each key purpose identifier in the extended key usage
   extension of the end-entity certificate MUST NOT appear in the
   excluded key purpose identifiers set.

   The special key purpose identifier anyExtendedKeyUsage is not treated
   differently than any other key purpose identifier in processing the
   constraints.  If the anyExtendedKeyUsage key purpose identifier
   appears in the extended key usage extension of the end-entity
   certificate, then the anyExtendedKeyUsage key purpose identifier MUST
   appear in the permitted key purpose identifiers set and the
   anyExtendedKeyUsage key purpose identifier MUST NOT appear in the
   excluded key purpose identifiers set.

Russ

---

From: Wei Chuang <[email-masked]>
Date: Thu, 19 May 2016 11:18:38 -0700

> worse outcomes in the past. Text suggestions welcome.

The current charter draft is thankfully brief, and it would be ideal to
keep that.  One thing that might help i.e. cover the issues you are
raising, is to add a statement about work items having a realistic path to
deployment.  Such a plan could be disclosed during the draft discussion.

-Wei