Re: [saag] Public key parameters in the signature algorithm —that is the question
Benjamin Kaduk <kaduk@mit.edu> Sun, 18 July 2021 22:29 UTC
Return-Path: <kaduk@mit.edu>
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1])
by ietfa.amsl.com (Postfix) with ESMTP id 563D53A11CA;
Sun, 18 Jul 2021 15:29:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.197
X-Spam-Level:
X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001,
SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 5QU9MsIBcq-K; Sun, 18 Jul 2021 15:28:59 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by ietfa.amsl.com (Postfix) with ESMTPS id BC8173A1203;
Sun, 18 Jul 2021 15:28:58 -0700 (PDT)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56)
(User authenticated as kaduk@ATHENA.MIT.EDU)
by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 16IMSoTx010843
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);
Sun, 18 Jul 2021 18:28:56 -0400
Date: Sun, 18 Jul 2021 15:28:49 -0700
From: Benjamin Kaduk <kaduk@mit.edu>
To: John Mattsson <john.mattsson=40ericsson.com@dmarc.ietf.org>
Cc: saag <saag@ietf.org>
Message-ID: <20210718222849.GA88594@kduck.mit.edu>
References: <HE1PR0701MB30506C4D58CF5F9CF476CAD689089@HE1PR0701MB3050.eurprd07.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <HE1PR0701MB30506C4D58CF5F9CF476CAD689089@HE1PR0701MB3050.eurprd07.prod.outlook.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/saag/6fHQ7wHzNuyLKAXv1y-R2dXpgik>
Subject: Re: [saag]
=?utf-8?q?Public_key_parameters_in_the_signature_algorith?=
=?utf-8?q?m_=E2=80=94that_is_the_question?=
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Advisory Group <saag.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/saag>,
<mailto:saag-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/saag/>
List-Post: <mailto:saag@ietf.org>
List-Help: <mailto:saag-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/saag>,
<mailto:saag-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 18 Jul 2021 22:29:03 -0000
Hi John, On Wed, Jun 23, 2021 at 08:35:24PM +0000, John Mattsson wrote: > Hi, > > There has been a lot of discussions in various groups recently on whether to have public key parameters also in the signature algorithm or not. There are significant differences between IETF protocols like PKIX, JOSE, COSE, TLS 1.2, TLS 1.3, and IKEv2. Many of the protocols are also internally inconsistent. The inconsistency has led to a lot of confusion for developers and people writing specifications. > > Looking at IETF protocols with signature algorithm registers: > > - PKIX/X.509 is consistent. There is no duplication of parameters between the public key algorithm and the signature algorithms. > > - TLS 1.2 is consistent. None of the signature algorithms include public key parameters. > > - COSE is inconsistent. COSE largely following PKIX. The exception is the signature algorithm ES256K that includes the public key parameter secp256k1. > > - JOSE is inconsistent. JOSE is mostly doing the opposite as COSE and includes many public key parameters in the signature algorithms. Exceptions are EdDSA that do not include the curve, and the RSA algorithms that do not include the key size. > > - IKEv2 is inconsistent. IKEv2 started its own registry where the ECDSA signature algorithms is bound to a curve, but the RSA signature algorithm does not include the key size. IKEv2 have since specified a way to use PKIX/X.509 registries where signature algorithms do not include any public key parameters. > > - TLS 1.3 is inconsistent. ECDSA, EdDSA, sm2sig_sm3, and gost include the curve, but eccsi_sha256, iso_ibs1, iso_ibs2, and iso_chinese_ibs. RSA does not include the key length. We didn't ask the experts to enforce anything about parameters in SignatureSchemes. Do you think we should? (The ongoing 8446bis would be an okay place to add such guidance, I think.) -Ben > - draft-ietf-httpbis-message-signatures is inconsistent. ECDSA includes curve, but RSA does not include key length and JOSE EdDSA does not include curve. > > I have seen at least the following arguments to include public key parameters in the signature algorithm: > 1. An implementation should know based on the signature algorithm that is support calculating the signature. > 2. The security level should follow from the signature algorithm > 3. Avoid using the same public key with two different algorithms > > My observations and thoughts: > - I think consistency is the most important property here. > - The protocols except PKIX, COSE, and TLS 1.2 seems to try to achieve 1. but fail as they are not consistent. > - None of the protocols above seem to strive for 2. > - Adding public key parameters to the signature algorithm does not seem to achieve 3. A way to achieve 3. would e.g., be to add signature algorithm OIDs to the Extended Key Usage and only use algorithms specified there. > > Cheers, > John > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag
- [saag] Public key parameters in the signature alg… John Mattsson
- Re: [saag] Public key parameters in the signature… Benjamin Kaduk
- Re: [saag] Public key parameters in the signature… Martin Thomson