Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63536C151990; Tue, 17 Sep 2024 16:17:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.105 X-Spam-Level: X-Spam-Status: No, score=-2.105 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=alkaline-solutions.com Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tgljAoBPy74o; Tue, 17 Sep 2024 16:17:20 -0700 (PDT) Received: from mail.alkaline-solutions.com (caesium6.alkaline.solutions [157.230.133.164]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B3C0C14CEFC; Tue, 17 Sep 2024 16:17:20 -0700 (PDT) From: David Waite DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alkaline-solutions.com; s=dkim; t=1726615039; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=kIIJSr2iKWNFJolTFhMOFOwhlDAdqYVE8ERPRJ9i5iA=; b=U4qKBPB4Wz9BBkB5WNvNkAg1bTh94kiYXjZYoPmBnx+2y/Y3XLhNKKlcwsbNBwwCozhVR5 sNwPiH8m3+EoOShk35Xa7tmT7ygo4LNp2GkvuBid+OQUh2wyySn/+tM0ALbUF9Cztl3+D3 pgwJoDOCRZlXijKWs59/s29EEVXi+y2JeldE7+Ycvq/50Zkonlj20ub7x1GWNkYBcPEsUc rPMjceooFa9Fuytlj9P9KLhQgI3QmmlumTy07tNawycP/0q0F7f6uZf+94xhrKbPJi1Aib ccyYopF91Qq2SXZFLbH/B5vjF0gZ6eU2qlOcIRvBpcd0RyUMRiUcgVkyu/zy0Q== Authentication-Results: mail.alkaline-solutions.com; auth=pass smtp.mailfrom=david@alkaline-solutions.com Message-Id: <769754A3-AAD0-4630-AEBC-4A4B0553ACBB@alkaline-solutions.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_01C86386-126E-48C1-8D29-D8017A97F2F4" Mime-Version: 1.0 Date: Tue, 17 Sep 2024 17:17:07 -0600 In-Reply-To: To: John Mattsson References: <5233A37F-2EA1-40CB-A3DA-EAEF885E52B0@gmail.com> X-Spamd-Bar: + Message-ID-Hash: GXVLJWNCAPELSSQZJZJVCJFIKFOBDSXE X-Message-ID-Hash: GXVLJWNCAPELSSQZJZJVCJFIKFOBDSXE X-MailFrom: david@alkaline-solutions.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-jose.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: JOSE WG , "cose@ietf.org" , Neil Madden X-Mailman-Version: 3.3.9rc4 Precedence: list Subject: =?utf-8?q?=5Bjose=5D_Re=3A_2nd_WGLC_for_draft-ietf-jose-fully-specified-algo?= =?utf-8?q?rithms_=28Fully_Specified_Algorithms=29?= List-Id: Javascript Object Signing and Encryption Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --Apple-Mail=_01C86386-126E-48C1-8D29-D8017A97F2F4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Sep 13, 2024, at 1:30=E2=80=AFAM, John Mattsson = wrote: >=20 > Hi, >=20 > As an individual, I agree with Neil=E2=80=99s comments. > = https://mailarchive.ietf.org/arch/msg/jose/JSlZI6oeyYHXFkG2PgHbG4YzghA/ >=20 > I have also pointed out in a separate mail that the following sentence = in not true: >=20 > =E2=80=9DThis is not a problem in practice, because RSA libraries = accommodate keys of different sizes without having to use different = code.=E2=80=9D > =20 > In addition to limitations on key length nlen, it is not uncommon that = RSA implementations have limitations on the exponent e. Could you provide more information here? I am only aware of a few = implementations (notably one included in Microsoft Windows) requiring it = to be a 32-bit value, not that they mandate 65537 or the like. >=20 > I have a hard time seeing why RSA domain parameters (nlen, e) and ECC = domain parameters (p, a, b, G, n, h) are treated completely differently. JOSE and COSE already only allow named curves to be specified, so = discussion of custom curve definitions may be getting out of scope here. Starting early with domain parameters being specified meant that RSA = implementations were expected to be able to operate over a range of = parameters for interoperability. There are also expectations that you = can evaluate the RSA parameters at runtime for appropriateness (such as = e needing to be odd) Starting early with pre-defined curves meant that a select set of curves = were often built into software, that was put into firmware, and = sometimes even used to design silicon. I do not know of a way to = evaluate the properties/safety of a custom curve at runtime. -DW= --Apple-Mail=_01C86386-126E-48C1-8D29-D8017A97F2F4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Sep 13, 2024, at 1:30=E2=80=AFAM, John Mattsson = <john.mattsson=3D40ericsson.com@dmarc.ietf.org> wrote:

Hi,

As an individual, I agree with Neil=E2=80=99s = comments.
https://mailarchive.ietf.org/arch/msg/jose/JSlZI6oeyYHXFkG2PgH= bG4YzghA/

I have also pointed out in a separate mail that the = following sentence in not true:

=E2=80=9DThis is not a problem in practice, because = RSA libraries accommodate keys of different sizes without having to use = different code.=E2=80=9D
 
In addition to limitations on key length nlen, it is not = uncommon that RSA implementations have limitations on the exponent e.

Could you provide more information = here? I am only aware of a few implementations (notably one included in = Microsoft Windows) requiring it to be a 32-bit value, not that they = mandate 65537 or the like.


I have a hard time seeing why RSA domain = parameters (nlen, e) and ECC domain = parameters (p, a, = b, G, n, h) are = treated completely differently. =

JOSE and COSE = already only allow named curves to be specified, so discussion of custom = curve definitions may be getting out of scope = here.

Starting early with domain parameters = being specified meant that RSA implementations were expected to be able = to operate over a range of parameters for interoperability. There are = also expectations that you can evaluate the RSA parameters at runtime = for appropriateness (such as e needing to be = odd)

Starting early with pre-defined curves = meant that a select set of curves were often built into software, that = was put into firmware, and sometimes even used to design silicon. I do = not know of a way to evaluate the properties/safety of a custom curve at = runtime.

<snip>

-D= W
= --Apple-Mail=_01C86386-126E-48C1-8D29-D8017A97F2F4--