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

[Russ Housley <[e-mail]>]

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 <[e-mail]> 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 <[e-mail] <mailto:[e-mail]>>
> Sent: 28 January 2021 16:18
> To: Rob Stradling <[e-mail] <mailto:[e-mail]>>
> Cc: Roman D. Danyliw <[e-mail] <mailto:[e-mail]>>; Ben Kaduk <[e-mail] <mailto:[e-mail]>>; Stephen Kent <[e-mail] <mailto:[e-mail]>>; IETF PKIX <[e-mail] <mailto:[e-mail]>>; Stefan Santesson <[e-mail] <mailto:[e-mail]>>; David Cooper <[e-mail] <mailto:[e-mail]>>; [e-mail] <mailto:[e-mail]><[e-mail] <mailto:[e-mail]>>; Stephen Farrell <[e-mail] <mailto:[e-mail]>>
> 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 <[e-mail] <mailto:[e-mail]>> 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 <[e-mail] <mailto:[e-mail]>>
>> Sent: 28 January 2021 16:07
>> To: Rob Stradling <[e-mail] <mailto:[e-mail]>>
>> Cc: Roman D. Danyliw <[e-mail] <mailto:[e-mail]>>; Ben Kaduk <[e-mail] <mailto:[e-mail]>>; Stephen Kent <[e-mail] <mailto:[e-mail]>>; IETF PKIX <[e-mail] <mailto:[e-mail]>>; Stefan Santesson <[e-mail] <mailto:[e-mail]>>; David Cooper <[e-mail] <mailto:[e-mail]>>; [e-mail] <mailto:[e-mail]><[e-mail] <mailto:[e-mail]>>; Stephen Farrell <[e-mail] <mailto:[e-mail]>>
>> 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 <[e-mail] <mailto:[e-mail]>> 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%7Ccbc3b1b2afb94a84540d08d8c3a86002%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637474475235070735%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=CzxiKY%2FEqSGRdy9AlPZzJb68MFfkiIbQmR2tL24VCUA%3D&reserved=0>
>> >
>> > --------------------------------------
>> > Type: Technical
>> > Reported by: Rob Stradling <[e-mail] <mailto:[e-mail]>>
>> >
>> > 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%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.
>> >
>> > 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