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

[Benjamin Kaduk <[e-mail]>]

On Thu, Jan 28, 2021 at 08:13:25AM -0800, Benjamin Kaduk wrote:
> On Thu, Jan 28, 2021 at 07:44:20AM -0800, RFC Errata System 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 <[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://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.
> 
> 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.

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