Re: [Technical Errata Reported] RFC5280 (6414)

> 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".

________________________________
From: Russ Housley <[email protected]>
Sent: 28 January 2021 16:42
To: Rob Stradling <[email protected]>
Cc: Roman D. Danyliw <[email protected]>; Ben Kaduk <[email protected]>; Stephen Kent <[email protected]>; IETF PKIX <[email protected]>; Stefan Santesson <[email protected]>; David Cooper <[email protected]>; [email protected] <[email protected]>; Stephen Farrell <[email protected]>
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:

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 protected]<mailto:[email protected]>> wrote:

> 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.

My Proposed Text is:
>   -- Key usage bits that may be consistent: digitalSignature
>   -- 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.

________________________________
From: Russ Housley <[email protected]<mailto:[email protected]>>
Sent: 28 January 2021 16:18
To: Rob Stradling <[email protected]<mailto:[email protected]>>
Cc: Roman D. Danyliw <[email protected]<mailto:[email protected]>>; Ben Kaduk <[email protected]<mailto:[email protected]>>; Stephen Kent <[email protected]<mailto:[email protected]>>; IETF PKIX <[email protected]<mailto:[email protected]>>; Stefan Santesson <[email protected]<mailto:[email protected]>>; David Cooper <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]><[email protected]<mailto:[email protected]>>; Stephen Farrell <[email protected]<mailto:[email protected]>>
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:

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

Russ

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

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 protected]<mailto:[email protected]>>
Sent: 28 January 2021 16:07
To: Rob Stradling <[email protected]<mailto:[email protected]>>
Cc: Roman D. Danyliw <[email protected]<mailto:[email protected]>>; Ben Kaduk <[email protected]<mailto:[email protected]>>; Stephen Kent <[email protected]<mailto:[email protected]>>; IETF PKIX <[email protected]<mailto:[email protected]>>; Stefan Santesson <[email protected]<mailto:[email protected]>>; David Cooper <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]><[email protected]<mailto:[email protected]>>; Stephen Farrell <[email protected]<mailto:[email protected]>>
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:

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 protected]<mailto:[email protected]>> wrote:
>
> 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://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>
>
> --------------------------------------
> Type: Technical
> Reported by: Rob Stradling <[email protected]<mailto:[email protected]>>
>
> 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://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.
>
> 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

_______________________________________________
pkix mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pkix