Subject: [lamps] Fwd: [Technical Errata Reported] RFC5280 (6414)

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 28 Jan 2021 08:59:14 -0800

FYI there's some ongoing discussion about this report on the pkix@ list:
https://mailarchive.ietf.org/arch/browse/pkix/

-Ben

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-masked]>
> 
> 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

---

From: Benjamin Kaduk <[email-masked]>
Date: Sun, 31 Jan 2021 13:19:11 -0800

On Thu, Jan 28, 2021 at 08:13:25AM -0800, Benjamin Kaduk wrote:
> 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

---

From: Ryan Sleevi <[email-masked]>
Date: Sun, 31 Jan 2021 17:32:16 -0500

On Sun, Jan 31, 2021 at 4:19 PM Benjamin Kaduk <[email-masked]> wrote:.

>   in any given certificate.

Hey Ben,

I think you were the only one that raised the concern about normative
force, but I think I'd disagree with you here, especially in light of the
work clarifying RFC 8813.

I think your proposed response would thus actually substantially change
things, by suggesting something that is presently treated as normative as
informative. While that's certainly one way to square things, I think that
probably moves too far in the opposite direction.

I think the same applies to your remark about "(but not by protocol)",
since the reflection of the keyUsage bits here within the textual comment
for EKU is actually a reflection of the TLS protocol when the PKIX work
first began (and continues to this day). Namely, the binding of keyUsage
bits to ciphersuite selection, and (both implicitly via spec and explicitly
via implementation) to the extendedKeyUsage.

So I don't think the premise of the response may be a bit mistaken: there
is a normative reason for both the restriction of both KU and EKU
(cross-protocol attacks, as we saw with QUIC / TLS 1.3), and the limitation
of the KU within an EKU (relevant to the how the given EKU makes use of the
key; in this case, the TLS ciphersuites associated with RSA and EC keys)

To that end, I'm perhaps missing what you mean by "doing so would raise the
prospect of conflicting restrictions imposed by different extend key usage
values". It's very intentional that, in "every major implementation", the
EKU is the primary means of preventing cross-protocol attacks enabled by
key reuse. If, for example, usage A required KU (1, 2) and usage B required
KU (3, 4), then it should be very much the fact that a single certificate
usable for both usage A and usage B (as distinct EKUs) would not be issued,
because it would enable the same set of cross-protocol/downgrade attacks
that we've seen plague SSL 2 -> SSL 3, SSL 3 -> TLS 1, and TLS <= 1.2 ->
TLS 1.3.

I do support the conclusion of this being "editorial that accidentally
became normative" (that is, that it "should" have been "and/or"), but I
think given the ramifications to key reuse, the rest of the text may swing
too far in overcorrecting in a way that would introduce security issues, or
at least require their careful discussion.