Re: [pkix] [Technical Errata Reported] RFC5280 (6414)
Ryan Sleevi <ryan-ietf@sleevi.com> Sun, 31 January 2021 22:32 UTC
Return-Path: <ryan.sleevi@gmail.com>
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0011E3A12D1; Sun, 31 Jan 2021 14:32:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.42
X-Spam-Level:
X-Spam-Status: No, score=-1.42 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HNf3NdZ0UqDn; Sun, 31 Jan 2021 14:32:27 -0800 (PST)
Received: from mail-pg1-f182.google.com (mail-pg1-f182.google.com [209.85.215.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 409203A12D0; Sun, 31 Jan 2021 14:32:27 -0800 (PST)
Received: by mail-pg1-f182.google.com with SMTP id j2so9079956pgl.0; Sun, 31 Jan 2021 14:32:27 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Pv1Vdo8QNsBeLSh9gTitqp+3pPdGpkWSQQilU3kcBYM=; b=NNrnlVTQU74ySGFx01AyzbiCDDFeAOFXw0nr+hSo4IfDmKX1pJgK/t2X7kDv+Xjuc+ C9/E8dFh+W1ksHTAxkl+5tcDFC8mSJxIFt9eWSfG/nlJWII6aKTEHOqV5Ox4CqDxzlCf TlBpnYrFC5M+UuLzci+VfT1QSTXaXa3xrDIBCbi19+4IMLZdwW43BJh9vvoGfcG7/DHV KmftrxVZ7eU9cxcM7Uu/HTuor/UhfRpGGHKUSbbgnQPhhg5xP+nd1iWlaWNumgNuXQhS pXRMGMzjjMqoQDWi+Hv7wEZFtfx0jIIFRfFP8B7ESD++hYJnONyxCu8NujCXdnEjgC2S 49cA==
X-Gm-Message-State: AOAM533RId8fa4UvGLC4wJs/7Cr+XFoBYPAdxq74nlHZlGcNgxmISWE2 +ZVNBuCFARUcXZefgZh47sWS5qi+JbU=
X-Google-Smtp-Source: ABdhPJzNOMz1hOZJUt9DU6Qgg0Dy/QSd/LWZnx1DSB+eX7JMxH5A+sb0Mi6wOOieAXABPxgeTmJXew==
X-Received: by 2002:a05:6a00:16c7:b029:1b6:68a6:985a with SMTP id l7-20020a056a0016c7b02901b668a6985amr13472660pfc.44.1612132346367; Sun, 31 Jan 2021 14:32:26 -0800 (PST)
Received: from mail-pj1-f51.google.com (mail-pj1-f51.google.com. [209.85.216.51]) by smtp.gmail.com with ESMTPSA id w67sm2782396pfb.79.2021.01.31.14.32.26 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 31 Jan 2021 14:32:26 -0800 (PST)
Received: by mail-pj1-f51.google.com with SMTP id z9so1248617pjl.5; Sun, 31 Jan 2021 14:32:26 -0800 (PST)
X-Received: by 2002:a17:90b:4d07:: with SMTP id mw7mr14607859pjb.172.1612132345978; Sun, 31 Jan 2021 14:32:25 -0800 (PST)
MIME-Version: 1.0
References: <20210128154420.4B40EF40715@rfc-editor.org> <20210128161318.GV21@kduck.mit.edu> <20210131211911.GQ21@kduck.mit.edu>
In-Reply-To: <20210131211911.GQ21@kduck.mit.edu>
From: Ryan Sleevi <ryan-ietf@sleevi.com>
Date: Sun, 31 Jan 2021 17:32:16 -0500
X-Gmail-Original-Message-ID: <CAErg=HH5wNY=3HFaUTitAcak+yj+d85Q0QAVbFJ6J-i7dkP-BQ@mail.gmail.com>
Message-ID: <CAErg=HH5wNY=3HFaUTitAcak+yj+d85Q0QAVbFJ6J-i7dkP-BQ@mail.gmail.com>
To: Benjamin Kaduk <kaduk@mit.edu>
Cc: RFC Errata System <rfc-editor@rfc-editor.org>, sharon.boeyen@entrust.com, "Roman D. Danyliw" <rdd@cert.org>, SPASM <spasm@ietf.org>, IETF PKIX <pkix@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000d026ab05ba39cf5f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/pkix/0i5MZcmBD_TPvHExo1lrQokMp9s>
Subject: Re: [pkix] [Technical Errata Reported] RFC5280 (6414)
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: PKIX Working Group <pkix.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pkix>, <mailto:pkix-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pkix/>
List-Post: <mailto:pkix@ietf.org>
List-Help: <mailto:pkix-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pkix>, <mailto:pkix-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 31 Jan 2021 22:32:29 -0000
On Sun, Jan 31, 2021 at 4:19 PM Benjamin Kaduk <kaduk@mit.edu> 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] [Technical Errata Reported] RFC5280 (6414) RFC Errata System
- Re: [pkix] [Technical Errata Reported] RFC5280 (6… Russ Housley
- Re: [pkix] [Technical Errata Reported] RFC5280 (6… Benjamin Kaduk
- Re: [pkix] [Technical Errata Reported] RFC5280 (6… Rob Stradling
- Re: [pkix] [Technical Errata Reported] RFC5280 (6… Russ Housley
- Re: [pkix] [Technical Errata Reported] RFC5280 (6… Rob Stradling
- Re: [pkix] [Technical Errata Reported] RFC5280 (6… Stefan Santesson
- Re: [pkix] [Technical Errata Reported] RFC5280 (6… Rob Stradling
- Re: [pkix] [Technical Errata Reported] RFC5280 (6… Russ Housley
- Re: [pkix] [Technical Errata Reported] RFC5280 (6… Benjamin Kaduk
- Re: [pkix] [Technical Errata Reported] RFC5280 (6… Rob Stradling
- Re: [pkix] [Technical Errata Reported] RFC5280 (6… Paul Hoffman
- Re: [pkix] [Technical Errata Reported] RFC5280 (6… Benjamin Kaduk
- Re: [pkix] [Technical Errata Reported] RFC5280 (6… Paul Hoffman
- Re: [pkix] [Technical Errata Reported] RFC5280 (6… Stephen Farrell
- Re: [pkix] [Technical Errata Reported] RFC5280 (6… Dan Harkins
- Re: [pkix] [Technical Errata Reported] RFC5280 (6… Paul Hoffman
- Re: [pkix] [Technical Errata Reported] RFC5280 (6… Benjamin Kaduk
- Re: [pkix] [Technical Errata Reported] RFC5280 (6… Ryan Sleevi