Subject: [Spasm] New Version Notification for draft-housley-spasm-eku-constraints-02.txt

From: Russ Housley <[email-masked]>
Date: Wed, 25 May 2016 11:32:01 -0400

I made many little changes, and I made three bigger ones based on the discussion on this list:

1) The extension may be critical or non-critical.

2) The extension syntax is changed to a CHOICE:

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

3) A end entity-certificate does not include an EKU extension is allowed to be used with any key purpose identifier, so a check in the path processing was added to handle this.

Russ

On May 25, 2016, at 11:16 AM, [email-masked] wrote:

> A new version of I-D, draft-housley-spasm-eku-constraints-02.txt
> has been successfully submitted by Russell Housley and posted to the
> IETF repository.
> 
> Name:		draft-housley-spasm-eku-constraints
> Revision:	02
> Title:		Extended Key Usage Constraints
> Document date:	2016-05-25
> Group:		Individual Submission
> Pages:		9
> URL:            https://www.ietf.org/internet-drafts/draft-housley-spasm-eku-constraints-02.txt
> Status:         https://datatracker.ietf.org/doc/draft-housley-spasm-eku-constraints/
> Htmlized:       https://tools.ietf.org/html/draft-housley-spasm-eku-constraints-02
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-housley-spasm-eku-constraints-02
> 
> 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.

---

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

Making good progress!

I read the draft.

>            excludedKeyPurposeIds    [1] KeyPurposeIds OPTIONAL }

OPTIONAL is not compatible with CHOICE. It should be:

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

This is also a good time to raise the SET vs. SEQUENCE issue.

I believe (firmly, but not going to die over it) that KeyPurposeIDs 
should be a SET SIZE (1..MAX) OF KeyPurposeId, not SEQUENCE.

A SEQUENCE is ordered. A SET is unordered. In DER, SET gets canonically 
ordered by the octet representation on the wire. Because we are talking 
about OBJECT IDENTIFIER, octet representation ordering has the 
convenient property of being identical to abstract OID ordering. E.g.:

0.0.1
0.0.1.1111
0.0.0.1112
2.14.2
2.14.22222
2.14.22222.333333
2.14.22223

etc.

A long time ago, Peter Gutmann published his X.509 Style Guide 
<https://www.cs.auckland.ac.nz/~pgut001/pubs/x509guide.txt>. Among other 
things, I recall that it recommends using SEQUENCE instead of SET where 
possible because of the DER ordering issue.

However, that advice is old. Computers are now much more powerful, and 
memory is more plentiful. Most importantly, we are talking about a SET 
OF OIDs, which are fixed and determinable (in both BER and DER 
encodings). Furthermore, since the algorithm here calls for intersecting 
and union-ing, you can save an ordering/comparison pass for every 
certificate in the path by ensuring that they are ordered on the wire. 
Essentially each step with SET requires O(n) instead of SEQUENCE, which 
requires O(n log n) or in the worst case O(n²).

The pile of OIDs is not ordered; neither should be its representation on 
the wire. A compliant parser should reject (i.e., "MUST NOT accept") 
invalid DER for this extension, because a CA should go to the trouble to 
order it properly with 2016 technology.

I don't know if there is a new ASN.1 constraint that enforces 
uniqueness. As I understand it, it's possible in theory to put duplicate 
OIDs in the SET OF or SEQUENCE OF. While it is harmless to do so, I 
would like a constraint expressed in the ASN.1 that makes it a true set, 
not a multiset. (I.e., no duplicates.)

> 3) A end entity-certificate does not include an EKU extension is allowed to be used with any key purpose identifier, so a check in the path processing was added to handle this.

Follow-up question: permittedKeyPurposeIDs can't be 0-length. What if a 
CA wants to restrict end-entity certificates so that no EKUs can be 
asserted whatsoever? Is that a valid use case, or not, and why?

(Note: I would propose a different algorithm description but I will 
leave it for now.)

Sean

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

---

From: Russ Housley <[email-masked]>
Date: Wed, 25 May 2016 15:05:45 -0400

>           excludedKeyPurposeIds    [1] KeyPurposeIds }

You are correct.  I went too fast in editing.

> I believe (firmly, but not going to die over it) that KeyPurposeIDs should be a SET SIZE (1..MAX) OF KeyPurposeId, not SEQUENCE.
> 
> A SEQUENCE is ordered. A SET is unordered. In DER, SET gets canonically ordered by the octet representation on the wire. Because we are talking about OBJECT IDENTIFIER, octet representation ordering has the convenient property of being identical to abstract OID ordering. E.g.:
> 
> 0.0.1
> 0.0.1.1111
> 0.0.0.1112
> 2.14.2
> 2.14.22222
> 2.14.22222.333333
> 2.14.22223
> 
> etc.

The EKU extension is:

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

This syntax was used to avoid the sort associated with SET.

I think we want to continue to avoid the sort at encode time, but we could certainly ask the CA to populate the sequence in a sorted order.

> 
> A long time ago, Peter Gutmann published his X.509 Style Guide <https://www.cs.auckland.ac.nz/~pgut001/pubs/x509guide.txt>. Among other things, I recall that it recommends using SEQUENCE instead of SET where possible because of the DER ordering issue.
> 
> However, that advice is old. Computers are now much more powerful, and memory is more plentiful. Most importantly, we are talking about a SET OF OIDs, which are fixed and determinable (in both BER and DER encodings). Furthermore, since the algorithm here calls for intersecting and union-ing, you can save an ordering/comparison pass for every certificate in the path by ensuring that they are ordered on the wire. Essentially each step with SET requires O(n) instead of SEQUENCE, which requires O(n log n) or in the worst case O(n²).
> 
> The pile of OIDs is not ordered; neither should be its representation on the wire. A compliant parser should reject (i.e., "MUST NOT accept") invalid DER for this extension, because a CA should go to the trouble to order it properly with 2016 technology.
> 
> I don't know if there is a new ASN.1 constraint that enforces uniqueness. As I understand it, it's possible in theory to put duplicate OIDs in the SET OF or SEQUENCE OF. While it is harmless to do so, I would like a constraint expressed in the ASN.1 that makes it a true set, not a multiset. (I.e., no duplicates.)

Again, I think we want to continue to avoid the sort at encode time, but we could certainly ask the CA to populate the sequence in a sorted order.

> Follow-up question: permittedKeyPurposeIDs can't be 0-length. What if a CA wants to restrict end-entity certificates so that no EKUs can be asserted whatsoever? Is that a valid use case, or not, and why?

Agree.  The syntax says:

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

So, there must be at least one OID in the sequence.

I’ll add a sentence to make that clear.

Russ

---

From: "Brown, Wendy (10421)" <[email-masked]>
Date: Wed, 25 May 2016 19:15:34 +0000

Just a question -
if Optional is not compatible with CHOICE does that mean if CHOICE is specified you cannot include both choices?

And I do agree that the KeyPurposeIds should be a SET rather than a SEQUENCE.

From: Sean Leonard [mailto:[email-masked]]
Sent: Wednesday, May 25, 2016 2:25 PM
To: [email-masked]
Subject: Re: [Spasm] New Version Notification for draft-housley-spasm-eku-constraints-02.txt

Making good progress!

I read the draft.

0.0.1
0.0.1.1111
0.0.0.1112
2.14.2
2.14.22222
2.14.22222.333333
2.14.22223

etc.

A long time ago, Peter Gutmann published his X.509 Style Guide <https://www.cs.auckland.ac.nz/~pgut001/pubs/x509guide.txt><https://urldefense.proofpoint.com/v2/url?u=https-3A__www.cs.auckland.ac.nz_-7Epgut001_pubs_x509guide.txt&d=CwMD-g&c=19TEyCb-E0do3cLmFgm9ItTXlbGQ5gmhRAlAtE256go&r=CBPcrHveVS6JeW8_gWG0NRDQwKKDbvlAqGnuc-opZ58&m=VASgWzxoJBamErB_bN0UHjtS6BC1PKHRiRHD5uQjnuM&s=ze9S7_JQIktViYWz9xqZA7ADV-2tkvEGX7YpzulVsC8&e=>. Among other things, I recall that it recommends using SEQUENCE instead of SET where possible because of the DER ordering issue.

(Note: I would propose a different algorithm description but I will leave it for now.)

Sean

Russ

On May 25, 2016, at 11:16 AM, [email-masked]<mailto:[email-masked]> wrote:

IETF repository.

Revision:  02

Pages:             9

URL:            https://www.ietf.org/internet-drafts/draft-housley-spasm-eku-constraints-02.txt<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_internet-2Ddrafts_draft-2Dhousley-2Dspasm-2Deku-2Dconstraints-2D02.txt&d=CwMD-g&c=19TEyCb-E0do3cLmFgm9ItTXlbGQ5gmhRAlAtE256go&r=CBPcrHveVS6JeW8_gWG0NRDQwKKDbvlAqGnuc-opZ58&m=VASgWzxoJBamErB_bN0UHjtS6BC1PKHRiRHD5uQjnuM&s=kBgiVh9gwyWd-KLeZ0LD7UF3UVtpTAXWxZQUKv-4SuE&e=>

Status:         https://datatracker.ietf.org/doc/draft-housley-spasm-eku-constraints/<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dhousley-2Dspasm-2Deku-2Dconstraints_&d=CwMD-g&c=19TEyCb-E0do3cLmFgm9ItTXlbGQ5gmhRAlAtE256go&r=CBPcrHveVS6JeW8_gWG0NRDQwKKDbvlAqGnuc-opZ58&m=VASgWzxoJBamErB_bN0UHjtS6BC1PKHRiRHD5uQjnuM&s=IoAtkB61ezbx2GbVl96D5Ui9Kcq2lCc1jpfWZFZAf9c&e=>

Htmlized:       https://tools.ietf.org/html/draft-housley-spasm-eku-constraints-02<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dhousley-2Dspasm-2Deku-2Dconstraints-2D02&d=CwMD-g&c=19TEyCb-E0do3cLmFgm9ItTXlbGQ5gmhRAlAtE256go&r=CBPcrHveVS6JeW8_gWG0NRDQwKKDbvlAqGnuc-opZ58&m=VASgWzxoJBamErB_bN0UHjtS6BC1PKHRiRHD5uQjnuM&s=a9Ishs0rFlwPSbLRd7sZwgV6wRmbQJff_dJxFsNYotc&e=>

Diff:           https://www.ietf.org/rfcdiff?url2=draft-housley-spasm-eku-constraints-02<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_rfcdiff-3Furl2-3Ddraft-2Dhousley-2Dspasm-2Deku-2Dconstraints-2D02&d=CwMD-g&c=19TEyCb-E0do3cLmFgm9ItTXlbGQ5gmhRAlAtE256go&r=CBPcrHveVS6JeW8_gWG0NRDQwKKDbvlAqGnuc-opZ58&m=VASgWzxoJBamErB_bN0UHjtS6BC1PKHRiRHD5uQjnuM&s=WbakqsBZ2cUL36zgSOuT0kfcP7ytmFek2YOUC4a3yEU&e=>

Abstract:

  RFC 5280.

Spasm mailing list

[email-masked]<mailto:[email-masked]>

https://www.ietf.org/mailman/listinfo/spasm<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_spasm&d=CwMD-g&c=19TEyCb-E0do3cLmFgm9ItTXlbGQ5gmhRAlAtE256go&r=CBPcrHveVS6JeW8_gWG0NRDQwKKDbvlAqGnuc-opZ58&m=VASgWzxoJBamErB_bN0UHjtS6BC1PKHRiRHD5uQjnuM&s=49XGhU3pu2uZVCgbBkDsCw5WbABqDg6AfR2UoBi5CDc&e=>

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: Russ Housley <[email-masked]>
Date: Wed, 25 May 2016 15:22:03 -0400

The syntax that I proposed in -01 allowed both to be specified.  Several people commented that a CA would only need one or the other, so I changed it to a CHOICE.  If you see a case where a CA would need both, please say so.

Russ

On May 25, 2016, at 3:15 PM, Brown, Wendy (10421) <[email-masked]> wrote:

> Just a question –
> 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]