Re: [Technical Errata Reported] RFC5280 (6414)

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

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