Re: [Technical Errata Reported] RFC5280 (6414)

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]> 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://www.rfc-editor.org/errata/eid6414
> 
> --------------------------------------
> Type: Technical
> Reported by: Rob Stradling <[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://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