Re: [Technical Errata Reported] RFC5280 (6414)

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

> 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?
>

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.

_______________________________________________
pkix mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pkix