Re: [jose] RFC 8037 "alg" quirkiness

Jim Schaad <> Sat, 19 September 2020 22:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DEBA13A080F for <>; Sat, 19 Sep 2020 15:42:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id F1zBH4VbVe96 for <>; Sat, 19 Sep 2020 15:42:47 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CE29A3A080C for <>; Sat, 19 Sep 2020 15:42:46 -0700 (PDT)
Received: from Jude ( by ( with Microsoft SMTP Server (TLS) id 15.0.1395.4; Sat, 19 Sep 2020 15:42:41 -0700
From: Jim Schaad <>
To: 'Anders Rundgren' <>, <>
References: <>
In-Reply-To: <>
Date: Sat, 19 Sep 2020 15:42:38 -0700
Message-ID: <039901d68ed6$2ed27ba0$8c7772e0$>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQIRfeCT23E7ULVkfNVtfdFMcnJlbKj6PJ6A
Content-Language: en-us
X-Originating-IP: []
Archived-At: <>
Subject: Re: [jose] RFC 8037 "alg" quirkiness
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Javascript Object Signing and Encryption <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 19 Sep 2020 22:42:49 -0000

Jumping back to the start.

-----Original Message-----
From: jose <> On Behalf Of Anders Rundgren
Sent: Saturday, August 29, 2020 11:58 PM
Subject: [jose] RFC 8037 "alg" quirkiness

I have just implemented support for Edwards curves in my JSON library.

Although it is certainly not a deal-breaker I find the use of "EdDSA" as a
generic Edwards algorithm identifier rather quirky since it departs from the
other JWS algorithms:

[JLS]  I do not find this at all in consistent with the way that the other
signature algorithms were handled, but that may just be me.  For the ECDSA
algorithms, the size of the hash is specified because it could be variable
across the different curve sizes.  So you can do ECDSA with SHA-512 and
P-256.  The requirement to specify the hash was needed to bring the number
of options down to just those that are fixed by the curve.

[JLS] For EdDSA, the hash function is fixed by the curve.  This would change
if different hash functions where allowed for the same curve but I do not
believe that this where ever be in danger of happening because it was
strongly argued that a single hash function was the correct approach.  Since
there was not a need to specify the hash function independent of the key,
there was no need to specify an EdDSA with SHA-512 and an EdDSA with
SHAKE-256 it was not done.


For curiosity reasons I took a peek at the initial draft which has (in my
opinion...) a more logical solution:

May I ask why this change was performed?

For JSF (JSON Signature Format) I will stick to the "00" scheme which also
permits use of ed25519ph and friends if needed:


jose mailing list