Subject: [pkix] [Technical Errata Reported] RFC5280 (6414)

From: RFC Errata System <[email-masked]>
Date: Thu, 28 Jan 2021 07:44:20 -0800 (PST)

The following errata report has been submitted for RFC5280,
"Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile".

--------------------------------------
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6414

--------------------------------------
Type: Technical
Reported by: Rob Stradling <[email-masked]>

Section: 4.2.1.12

Original Text
-------------
   id-kp-serverAuth             OBJECT IDENTIFIER ::= { id-kp 1 }
   -- TLS WWW server authentication
   -- Key usage bits that may be consistent: digitalSignature,
   -- keyEncipherment or keyAgreement

Corrected Text
--------------
   id-kp-serverAuth             OBJECT IDENTIFIER ::= { id-kp 1 }
   -- TLS WWW server authentication
   -- Key usage bits that may be consistent: digitalSignature
   -- and/or (keyEncipherment or keyAgreement)

Notes
-----
In https://github.com/zmap/zlint/issues/553 there's been some disagreement and confusion about how to correctly interpret the "or" in the Original Text.  "You can only set one of these three bits" is one interpretation, and it's hard to argue that this interpretation is inconsistent with the Original Text.

However, digitalSignature+keyEncipherment makes sense for an RSA leaf certificate, and digitalSignature+keyAgreement makes sense for an ECC leaf certificate.  Both are widely used, to enable ephemeral and non-ephemeral TLS ciphersuites in conjunction with a single server certificate.

Given that RFC5480 section 3 explicitly permits digitalSignature+keyAgreement in an ECC leaf certificate, I think it's likely that my proposed Corrected Text conveys the RFC5280 authors' intended meaning.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC5280 (draft-ietf-pkix-rfc3280bis-11)
--------------------------------------
Title               : Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
Publication Date    : May 2008
Author(s)           : D. Cooper, S. Santesson, S. Farrell, S. Boeyen, R. Housley, W. Polk
Category            : PROPOSED STANDARD
Source              : Public-Key Infrastructure (X.509)
Area                : Security
Stream              : IETF
Verifying Party     : IESG

---

From: Russ Housley <[email-masked]>
Date: Thu, 28 Jan 2021 11:07:20 -0500

Rob:

The proposed rewording of the comment is not correct.  Consider an ECDSA key that will be used with TLS 1.3.  In that case, only the digitalSignature key usage would be set.

I think the original OR is correct.

Russ

> On Jan 28, 2021, at 10:44 AM, RFC Errata System <[email-masked]> wrote:
>

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 28 Jan 2021 08:13:18 -0800

> "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile".

I would be inclined to mark this as "editorial" and "hold for document
update".  Given that across the list of EKU values both "or" and "and/or"
are used, it seems like there was probably some intent to distinguish
between them, but I don't see that we will get clear agreement on what wa
intended at the time of publication.

That said, having looked at the referenced github issue, I'm pretty
surprised that there has been so much discussion.  My understanding is that
keyUsage and extendedKeyUsage both can act to restrict the usability of the
certificate, but they do so independently, and either can be absent (in
which case the absent extension does not restrict anything).  So, if you
have an EKU with id-kp-serverAuth and you have a keyUsage with none of the
listed three bits set, you're not supposed to actually be able to use that
cert for TLS WWW server authentication, since you'd need to use the key for
at least one of digital signature, key encipherment, or key agreement, but
the particular keyUsage forbids all of those.  AFAICT that's the core point
that this section is making, in terms of "consistency" between the
otherwise independent extensions -- if you want to be able to use the given
EKU at all, you either need to not have keyUsage or you're going to need
*something* from the given list.  But how you pick that "something" and
what it is just operates on the normal rules for keyUsage, and there are
very few rules that restrict which collections of keyUsage bits can be set
at the same time.  So I'm not sure how one would argue that there is a lot
of exclusive-or going on amongst the listed bits just based on the spec
requirements.  (The realities of what a given key type can do with a given
crypto algorithm is another matter, but I'm not convinced it's terribly
relevant for the purposes of interpreting this text.)

-Ben

---

From: Rob Stradling <[email-masked]>
Date: Thu, 28 Jan 2021 16:17:19 +0000

Hi Russ.

I'm afraid I don't understand your objection.  Your use case of setting only the digitalSignature bit is permitted both by the Original Text and by my Proposed Text.  (With my Proposed Text, you would choose the "or" option of the "and/or" instead of the "and" option).

The reason for the erratum is that neither digitalSignature+keyEncipherment nor digitalSignature+keyAgreement seem to be permitted by the Original Text.

________________________________
From: Russ Housley <[email-masked]>
Sent: 28 January 2021 16:07
To: Rob Stradling <[email-masked]>
Cc: Roman D. Danyliw <[email-masked]>; Ben Kaduk <[email-masked]>; Stephen Kent <[email-masked]>; IETF PKIX <[email-masked]>; Stefan Santesson <[email-masked]>; David Cooper <[email-masked]>; [email-masked] <[email-masked]>; Stephen Farrell <[email-masked]>
Subject: Re: [Technical Errata Reported] RFC5280 (6414)

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.

Rob:

Russ

> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Ferrata%2Feid6414&amp;data=04%7C01%7Crob%40sectigo.com%7Cdce250f148ea4d995db108d8c3a6ce56%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637474468512413977%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=8hy5qssHrRM%2BEOM2NX8rEJSJqGV%2FWhu7top4hdmsXgU%3D&amp;reserved=0
>
> In https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fzmap%2Fzlint%2Fissues%2F553&amp;data=04%7C01%7Crob%40sectigo.com%7Cdce250f148ea4d995db108d8c3a6ce56%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637474468512413977%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=Kf06%2FZ9o9VIMBcNRiCOk2L%2FUNA7dlgCP6ywIYJZH37I%3D&amp;reserved=0 there's been some disagreement and confusion about how to correctly interpret the "or" in the Original Text.  "You can only set one of these three bits" is one interpretation, and it's hard to argue that this interpretation is inconsistent with the Original Text.
>

---

From: Russ Housley <[email-masked]>
Date: Thu, 28 Jan 2021 11:18:31 -0500

Rob:

In my example, neither the keyEncipherment nor the keyAgreement bit is set.

Russ

> On Jan 28, 2021, at 11:17 AM, Rob Stradling <[email-masked]> wrote:
> 
> Hi Russ.
> 
> From: Russ Housley <[email-masked] <mailto:[email-masked]>>
> To: Rob Stradling <[email-masked] <mailto:[email-masked]>>
> Cc: Roman D. Danyliw <[email-masked] <mailto:[email-masked]>>; Ben Kaduk <[email-masked] <mailto:[email-masked]>>; Stephen Kent <[email-masked] <mailto:[email-masked]>>; IETF PKIX <[email-masked] <mailto:[email-masked]>>; Stefan Santesson <[email-masked] <mailto:[email-masked]>>; David Cooper <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]><[email-masked] <mailto:[email-masked]>>; Stephen Farrell <[email-masked] <mailto:[email-masked]>>
> > On Jan 28, 2021, at 10:44 AM, RFC Errata System <[email-masked] <mailto:[email-masked]>> wrote:
> >
> > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Ferrata%2Feid6414&amp;data=04%7C01%7Crob%40sectigo.com%7Cdce250f148ea4d995db108d8c3a6ce56%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637474468512413977%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=8hy5qssHrRM%2BEOM2NX8rEJSJqGV%2FWhu7top4hdmsXgU%3D&amp;reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Ferrata%2Feid6414&amp;data=04%7C01%7Crob%40sectigo.com%7Cdce250f148ea4d995db108d8c3a6ce56%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637474468512413977%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=8hy5qssHrRM%2BEOM2NX8rEJSJqGV%2FWhu7top4hdmsXgU%3D&amp;reserved=0>
> >
> > Reported by: Rob Stradling <[email-masked] <mailto:[email-masked]>>
> >
> > Section: 4.2.1.12
> >
> > Original Text
> > -------------
> > In https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fzmap%2Fzlint%2Fissues%2F553&amp;data=04%7C01%7Crob%40sectigo.com%7Cdce250f148ea4d995db108d8c3a6ce56%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637474468512413977%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=Kf06%2FZ9o9VIMBcNRiCOk2L%2FUNA7dlgCP6ywIYJZH37I%3D&amp;reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fzmap%2Fzlint%2Fissues%2F553&amp;data=04%7C01%7Crob%40sectigo.com%7Cdce250f148ea4d995db108d8c3a6ce56%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637474468512413977%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=Kf06%2FZ9o9VIMBcNRiCOk2L%2FUNA7dlgCP6ywIYJZH37I%3D&amp;reserved=0> there's been some disagreement and confusion about how to correctly interpret the "or" in the Original Text.  "You can only set one of these three bits" is one interpretation, and it's hard to argue that this interpretation is inconsistent with the Original Text.
> >

---

From: Rob Stradling <[email-masked]>
Date: Thu, 28 Jan 2021 16:27:21 +0000

> In my example, neither the keyEncipherment nor the keyAgreement bit is set.

Hi Russ.  I realize that, and I still say that my Proposed Text is compatible with your example.

>   -- and/or (keyEncipherment or keyAgreement)

The "and/or" part means that you can choose between these two options:

Option 1: digitalSignature and (keyEncipherment or keyAgreement)
Option 2: digitalSignature or (keyEncipherment or keyAgreement)

Setting just the digitalSignature bit, without keyEncipherment and without keyAgreement, is consistent with Option 2.

Sent: 28 January 2021 16:18

Rob:

Russ

On Jan 28, 2021, at 11:17 AM, Rob Stradling <[email-masked]<mailto:[email-masked]>> wrote:

Hi Russ.

________________________________
From: Russ Housley <[email-masked]<mailto:[email-masked]>>
Sent: 28 January 2021 16:07
To: Rob Stradling <[email-masked]<mailto:[email-masked]>>
Cc: Roman D. Danyliw <[email-masked]<mailto:[email-masked]>>; Ben Kaduk <[email-masked]<mailto:[email-masked]>>; Stephen Kent <[email-masked]<mailto:[email-masked]>>; IETF PKIX <[email-masked]<mailto:[email-masked]>>; Stefan Santesson <[email-masked]<mailto:[email-masked]>>; David Cooper <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]><[email-masked]<mailto:[email-masked]>>; Stephen Farrell <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Technical Errata Reported] RFC5280 (6414)

Rob:

Russ

> On Jan 28, 2021, at 10:44 AM, RFC Errata System <[email-masked]<mailto:[email-masked]>> wrote:
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Ferrata%2Feid6414&amp;data=04%7C01%7Crob%40sectigo.com%7Cdce250f148ea4d995db108d8c3a6ce56%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637474468512413977%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=8hy5qssHrRM%2BEOM2NX8rEJSJqGV%2FWhu7top4hdmsXgU%3D&amp;reserved=0<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Ferrata%2Feid6414&data=04%7C01%7Crob%40sectigo.com%7Ccbc3b1b2afb94a84540d08d8c3a86002%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637474475235070735%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=CzxiKY%2FEqSGRdy9AlPZzJb68MFfkiIbQmR2tL24VCUA%3D&reserved=0>
>
> Reported by: Rob Stradling <[email-masked]<mailto:[email-masked]>>
>
> Section: 4.2.1.12
>
> Original Text
> -------------
> In https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fzmap%2Fzlint%2Fissues%2F553&amp;data=04%7C01%7Crob%40sectigo.com%7Cdce250f148ea4d995db108d8c3a6ce56%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637474468512413977%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=Kf06%2FZ9o9VIMBcNRiCOk2L%2FUNA7dlgCP6ywIYJZH37I%3D&amp;reserved=0<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fzmap%2Fzlint%2Fissues%2F553&data=04%7C01%7Crob%40sectigo.com%7Ccbc3b1b2afb94a84540d08d8c3a86002%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637474475235080682%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=5et7x5%2F7VXWEh6OwZLlWFkpMPScvHFC4tkPPOf3E%2FDM%3D&reserved=0> there's been some disagreement and confusion about how to correctly interpret the "or" in the Original Text.  "You can only set one of these three bits" is one interpretation, and it's hard to argue that this interpretation is inconsistent with the Original Text.
>

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 28 Jan 2021 17:30:08 +0100

Russ,

If I read the proposal correct Rob is providing text where the following is allowed:

DS
KA
KE
DS + KA
DS + KE

And he argues that the current wording suggest that only the following is allowed:

DS
KA
KE

Right?

(DS = digitalISignature, KA = keyAgreement, KE = keyEncipherment)

Stefan Santesson 

From: Russ Housley <[email-masked]>
Date: Thursday, 28 January 2021 at 17:18
To: Rob Stradling <[email-masked]>
Cc: "Roman D. Danyliw" <[email-masked]>, Ben Kaduk <[email-masked]>, Stephen Kent <[email-masked]>, IETF PKIX <[email-masked]>, Stefan Santesson <[email-masked]>, David Cooper <[email-masked]>, Tim Polk <[email-masked]>, Stephen Farrell <[email-masked]>
Subject: Re: [Technical Errata Reported] RFC5280 (6414)

Rob:

Russ

Hi Russ.

Cc: Roman D. Danyliw <[email-masked]>; Ben Kaduk <[email-masked]>; Stephen Kent <[email-masked]>; IETF PKIX <[email-masked]>; Stefan Santesson <[email-masked]>; David Cooper <[email-masked]>; [email-masked]<[email-masked]>; Stephen Farrell <[email-masked]>

Rob:

Russ

---

From: Rob Stradling <[email-masked]>
Date: Thu, 28 Jan 2021 16:33:46 +0000

Thanks Stefan.  Yes, that's my intention.

________________________________
From: Stefan Santesson <[email-masked]>
Sent: 28 January 2021 16:30
To: Russ Housley <[email-masked]>; Rob Stradling <[email-masked]>
Cc: Roman D. Danyliw <[email-masked]>; Ben Kaduk <[email-masked]>; Stephen Kent <[email-masked]>; IETF PKIX <[email-masked]>; David Cooper <[email-masked]>; [email-masked] <[email-masked]>; Stephen Farrell <[email-masked]>
Subject: Re: [Technical Errata Reported] RFC5280 (6414)

Russ,

  *   DS
  *   KA
  *   KE
  *   DS + KA
  *   DS + KE

  *   DS
  *   KA
  *   KE

Right?

Stefan Santesson

Rob:

Russ

Hi Russ.

Rob:

Russ

> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Ferrata%2Feid6414&amp;data=04%7C01%7Crob%40sectigo.com%7Cdce250f148ea4d995db108d8c3a6ce56%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637474468512413977%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=8hy5qssHrRM%2BEOM2NX8rEJSJqGV%2FWhu7top4hdmsXgU%3D&amp;reserved=0<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Ferrata%2Feid6414&data=04%7C01%7Crob%40sectigo.com%7C375095cbbb5c46d8215808d8c3a9fff5%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637474482205572588%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=n7IgeqJYQHXwaB1UEcUQzv3Bfu11TQnnBLZumkJ4jdU%3D&reserved=0>
>
> In https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fzmap%2Fzlint%2Fissues%2F553&amp;data=04%7C01%7Crob%40sectigo.com%7Cdce250f148ea4d995db108d8c3a6ce56%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637474468512413977%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=Kf06%2FZ9o9VIMBcNRiCOk2L%2FUNA7dlgCP6ywIYJZH37I%3D&amp;reserved=0<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fzmap%2Fzlint%2Fissues%2F553&data=04%7C01%7Crob%40sectigo.com%7C375095cbbb5c46d8215808d8c3a9fff5%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637474482205572588%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=9nVGPOAgXuaBj09U2nxRVPTJxHaoKV3NNJNYTVJTxFk%3D&reserved=0> there's been some disagreement and confusion about how to correctly interpret the "or" in the Original Text.  "You can only set one of these three bits" is one interpretation, and it's hard to argue that this interpretation is inconsistent with the Original Text.
>

---

From: Russ Housley <[email-masked]>
Date: Thu, 28 Jan 2021 11:42:21 -0500

Rob:

I worry that the rewording will lead to similar discussions of the "and/or".  We really want any combination of digitalSignature, keyEncipherment, and keyAgreement bits that is consistent with the public key.

Russ

> On Jan 28, 2021, at 11:27 AM, Rob Stradling <[email-masked]> wrote:
> 
>> On Jan 28, 2021, at 11:17 AM, Rob Stradling <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Hi Russ.
>> 
>> > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Ferrata%2Feid6414&amp;data=04%7C01%7Crob%40sectigo.com%7Cdce250f148ea4d995db108d8c3a6ce56%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637474468512413977%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=8hy5qssHrRM%2BEOM2NX8rEJSJqGV%2FWhu7top4hdmsXgU%3D&amp;reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Ferrata%2Feid6414&data=04%7C01%7Crob%40sectigo.com%7Ccbc3b1b2afb94a84540d08d8c3a86002%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637474475235070735%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=CzxiKY%2FEqSGRdy9AlPZzJb68MFfkiIbQmR2tL24VCUA%3D&reserved=0>
>> >
>> > In https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fzmap%2Fzlint%2Fissues%2F553&amp;data=04%7C01%7Crob%40sectigo.com%7Cdce250f148ea4d995db108d8c3a6ce56%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637474468512413977%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=Kf06%2FZ9o9VIMBcNRiCOk2L%2FUNA7dlgCP6ywIYJZH37I%3D&amp;reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fzmap%2Fzlint%2Fissues%2F553&data=04%7C01%7Crob%40sectigo.com%7Ccbc3b1b2afb94a84540d08d8c3a86002%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637474475235080682%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=5et7x5%2F7VXWEh6OwZLlWFkpMPScvHFC4tkPPOf3E%2FDM%3D&reserved=0> there's been some disagreement and confusion about how to correctly interpret the "or" in the Original Text.  "You can only set one of these three bits" is one interpretation, and it's hard to argue that this interpretation is inconsistent with the Original Text.
>> >

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 28 Jan 2021 08:46:21 -0800

I agree with Russ -- in my reading, this text is not adding any new
requirements on what combinations of keyUsage bits are "permitted" by the
spec.  Its primary purpose is to note that if you have a keyUsage at all,
you have to have at laest one of those bits set in order for the EKU in
question to be usable.  As a secondary purpose it may be providing
commentary on what combinations of keyUsage bits make sense to apply given
currently existing key types, but that commentary does not seem to have
normative force, to me.

-Ben

---

From: Rob Stradling <[email-masked]>
Date: Thu, 28 Jan 2021 16:47:01 +0000

> I worry that the rewording will lead to similar discussions of the "and/or"

That potential problem already exists, because "and/or" is used in the descriptions of all (except one) of the other "key usage purposes".

Sent: 28 January 2021 16:42

Rob:

Russ

Rob:

Russ

Hi Russ.

Rob:

Russ

> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Ferrata%2Feid6414&amp;data=04%7C01%7Crob%40sectigo.com%7Cdce250f148ea4d995db108d8c3a6ce56%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637474468512413977%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=8hy5qssHrRM%2BEOM2NX8rEJSJqGV%2FWhu7top4hdmsXgU%3D&amp;reserved=0<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Ferrata%2Feid6414&data=04%7C01%7Crob%40sectigo.com%7C9ba84a47b69a45ac68f108d8c3abb55d%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637474489984427908%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=liz8L9ue%2BmkMnZIY71EMOH9US5p2%2FVuuZ50M%2FMZVmKI%3D&reserved=0>
>
> In https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fzmap%2Fzlint%2Fissues%2F553&amp;data=04%7C01%7Crob%40sectigo.com%7Cdce250f148ea4d995db108d8c3a6ce56%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637474468512413977%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=Kf06%2FZ9o9VIMBcNRiCOk2L%2FUNA7dlgCP6ywIYJZH37I%3D&amp;reserved=0<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fzmap%2Fzlint%2Fissues%2F553&data=04%7C01%7Crob%40sectigo.com%7C9ba84a47b69a45ac68f108d8c3abb55d%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637474489984437866%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=zhrD5%2F0VMZq2a1rCXqF1stqynRnn%2B85QGOmQ5iCYZGI%3D&reserved=0> there's been some disagreement and confusion about how to correctly interpret the "or" in the Original Text.  "You can only set one of these three bits" is one interpretation, and it's hard to argue that this interpretation is inconsistent with the Original Text.
>

---

From: "Paul Hoffman" <[email-masked]>
Date: Thu, 28 Jan 2021 09:34:51 -0800

I propose that this erratum be rejected outright. It is clear that the 
current text is unclear, particularly with the passage of time. The way 
to correct that is with a new Internet Draft that updates 5280, with a 
lot more words than just the limited space in the ASN.1 comment.

--Paul Hoffman

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 28 Jan 2021 10:08:58 -0800

> lot more words than just the limited space in the ASN.1 comment.

So, your stance is that the current text is unclear, which should be
remedied by a document update?  I'm not sure how that implies "rejected" as
opposed to "hold for document update"...

-Ben

---

From: "Paul Hoffman" <[email-masked]>
Date: Thu, 28 Jan 2021 10:39:30 -0800

> opposed to "hold for document update"...

Because I don't think that the document update will update the meaning 
just by modifying these ASN.1 comments. In fact, I think it should not. 
Instead, there should be a paragraph or two about the meaning, and then 
update the ASN.1 to not include comments.

--Paul Hoffman

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 28 Jan 2021 20:03:14 +0000

On 28/01/2021 17:34, Paul Hoffman wrote:
> The way to correct that is with a new Internet Draft that updates 5280,

Hmm. That sounds like a way to waste a few years
of someone's life.

S.

---

From: Dan Harkins <[email-masked]>
Date: Thu, 28 Jan 2021 12:20:17 -0800

> Hmm. That sounds like a way to waste a few years

   +5

-- 
"The object of life is not to be on the side of the majority, but to
escape finding oneself in the ranks of the insane." -- Marcus Aurelius

---

From: "Paul Hoffman" <[email-masked]>
Date: Thu, 28 Jan 2021 13:17:09 -0800

> Hmm. That sounds like a way to waste a few years

The folks in the CABForum do this regularly. They are the ones who would 
care the most about definitions such as the one that started this 
thread. I have no problem letting them spend all the time they want.

--Paul Hoffman

---

From: Benjamin Kaduk <[email-masked]>
Date: Sun, 31 Jan 2021 13:19:11 -0800

> intended at the time of publication.

In light of the subsequent discussion, my new proposal is to adopt Paul
Hoffman's suggestion and use "editorial"+"rejected", with a verifier note
along the lines of:

  This errata report correctly notes that the description for other extended
  key usage values appear to differentiate between "or" and "and/or".
  However, the suggestion that the lists of "key usage bits that may be
  consistent" with a given extended key usage value are somehow restrictive
  with normative force on which key usage bits can appear seems to be based
  on a mistaken premise.  What key usage bits can appear are governed by the
  rules for the key usage extension, which are in practice (but not by
  protocol) limited by the capabilities of current cryptographic algorithms,
  and the descriptive text here seems to just be an attempt to reflect those
  algorithmic limitations.  It should not be interpreted as making a
  normative restriction on which key usage bits can appear with a given
  extended key usage value -- doing so would raise the prospect of
  conflicting restrictions imposed by different extended key usage values,
  and it is well-known that multiple extended key usage values are permitted
  in any given certificate.

Any other comments?

Thanks,

Ben

---

From: Ryan Sleevi <[email-masked]>
Date: Sun, 31 Jan 2021 17:32:16 -0500

On Sun, Jan 31, 2021 at 4:19 PM Benjamin Kaduk <[email-masked]> wrote:.

>   in any given certificate.

Hey Ben,

I think you were the only one that raised the concern about normative
force, but I think I'd disagree with you here, especially in light of the
work clarifying RFC 8813.

I think your proposed response would thus actually substantially change
things, by suggesting something that is presently treated as normative as
informative. While that's certainly one way to square things, I think that
probably moves too far in the opposite direction.

I think the same applies to your remark about "(but not by protocol)",
since the reflection of the keyUsage bits here within the textual comment
for EKU is actually a reflection of the TLS protocol when the PKIX work
first began (and continues to this day). Namely, the binding of keyUsage
bits to ciphersuite selection, and (both implicitly via spec and explicitly
via implementation) to the extendedKeyUsage.

So I don't think the premise of the response may be a bit mistaken: there
is a normative reason for both the restriction of both KU and EKU
(cross-protocol attacks, as we saw with QUIC / TLS 1.3), and the limitation
of the KU within an EKU (relevant to the how the given EKU makes use of the
key; in this case, the TLS ciphersuites associated with RSA and EC keys)

To that end, I'm perhaps missing what you mean by "doing so would raise the
prospect of conflicting restrictions imposed by different extend key usage
values". It's very intentional that, in "every major implementation", the
EKU is the primary means of preventing cross-protocol attacks enabled by
key reuse. If, for example, usage A required KU (1, 2) and usage B required
KU (3, 4), then it should be very much the fact that a single certificate
usable for both usage A and usage B (as distinct EKUs) would not be issued,
because it would enable the same set of cross-protocol/downgrade attacks
that we've seen plague SSL 2 -> SSL 3, SSL 3 -> TLS 1, and TLS <= 1.2 ->
TLS 1.3.

I do support the conclusion of this being "editorial that accidentally
became normative" (that is, that it "should" have been "and/or"), but I
think given the ramifications to key reuse, the rest of the text may swing
too far in overcorrecting in a way that would introduce security issues, or
at least require their careful discussion.