Re: [jose] RFC 8037 "alg" quirkiness

Anders Rundgren <> Wed, 16 September 2020 13:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F3A203A0CB8 for <>; Wed, 16 Sep 2020 06:01:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Status: No, score=-2.099 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, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 23vzxXQdBAya for <>; Wed, 16 Sep 2020 06:01:11 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::630]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 117BC3A0C88 for <>; Wed, 16 Sep 2020 06:01:11 -0700 (PDT)
Received: by with SMTP id z23so10160908ejr.13 for <>; Wed, 16 Sep 2020 06:01:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=bkcgaxOFW1n6/JG15q8hsKv6UxVt+DfhxrmRxxdVhPM=; b=AUhzoLLx8/8MG+eMeLBwopKdeQ81nxZ1DIzPBjXluCNOWuDwe9bHqkXYKmFC/vxdY7 oJ5rP7yrj6pL7vWJLV5fKYflGyoMen99hzhZX2jN9TO8MXr+t4uVkv4se4LC+IY8vHac 7ZKXW1JNZmbsRRzD7bItDQGb0ljF6ZIhW6M9FqhhwM3vTuwYLQVh4PazN2no4s1DnMGQ VpLFhxhc2HBflNchtfIjXpRcwdW3dYptfKlDfml1A5U58wZD9pOftJ+qI8+bj73TnvvJ ZJVFrd24DW13Zfq7cz87Cgcn6KeTmD88dkQ24Xm52t4mUqEkw3PV5hj5fgZTM+iiXm5K 9kEA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=bkcgaxOFW1n6/JG15q8hsKv6UxVt+DfhxrmRxxdVhPM=; b=AeeggD4SzGwXVqfzbSTti+BkXLOTXqwEAjU+itLeBc51WFm+37VIKucksRSNyRuhsC YtrdparZctswQ8jdCDc1NeRpQ2PbdOxng5rMHyRX1SDq+iDCZ2hMoozSUoIdTEjXd1Vm oQ5Nizj4iGjLJUWSSI6Q5C4YFDJY9wXenEdV1f3gtOX29hTAQry3p9BxJXuwqmLeb5Al hhah6OFEFez5VT4GllghdbRsENzvI6T55oHGroQyp7G5xe7/WK8A3Tp5wGuX+37k8fBV 2xighq69SmZDJ+79py6kE+Kfz+0pcOtO4fbtwkaq7F9N3xwuW+HtVfMoyxb3Q+KWVXSO +d3g==
X-Gm-Message-State: AOAM532MBl5E0zixWJ6HU7Fc9Z5ia9DPnH6b5/F1EAY+1OfpmSZ9d+U7 p8IPAhm2WAZWDrtA9OWD5UZpOmUYcu0WzA==
X-Google-Smtp-Source: ABdhPJxruym6wK1U8lwp7GsB5bSqlgHgMApmVVLYOm9bjA+fAdHcUBxnavYmx7a2bHFA2VuuY/6CBA==
X-Received: by 2002:a17:906:c0d0:: with SMTP id bn16mr14020947ejb.279.1600261269062; Wed, 16 Sep 2020 06:01:09 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id bc18sm13768513edb.66.2020. (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 16 Sep 2020 06:01:08 -0700 (PDT)
To: Ilari Liusvaara <>, "" <>
References: <> <> <20200916123043.GB1653297@LK-Perkele-VII>
From: Anders Rundgren <>
Message-ID: <>
Date: Wed, 16 Sep 2020 15:01:06 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0
MIME-Version: 1.0
In-Reply-To: <20200916123043.GB1653297@LK-Perkele-VII>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
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: Wed, 16 Sep 2020 13:01:13 -0000

On 2020-09-16 14:30, Ilari Liusvaara wrote:
> On Sun, Aug 30, 2020 at 08:10:17AM +0100, Neil Madden wrote:
>>> On 30 Aug 2020, at 07:58, Anders Rundgren <> wrote:

Hi Ilari, thanx for the explanation.

I guessed that the motive for changing the 00 spec was because no
other algorithm was considered useful.

Personally, I rather noted the "deviation" in how things were
expressed compared to the EC algorithms.

It is a bit in the same vein as JWS's Base64Url-encoding all binary
elements except for "x5c".

I'm apparently "allergic" to asymmetry :-)

>>> I have just implemented support for Edwards curves in my JSON
>>> library.
> You mean JOSE or JWS? Because JSON is a data model and encoding of
> it. :-)

My JSON tools/library does indeed have integrated support for signatures
and encryption, although based on RFC 8785 rather than forcing the
entire caboodle to be in Base64Url or relying on HTTP headers holding
detached JWS signatures (which does not permit simple serialization,
embedding, or counter-signing) used by several Open Banking schemes.


>>> 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:
>>> For curiosity reasons I took a peek at the initial draft which has
>>> (in my opinion...) a more logical solution:
> On weird changes, I find the member name changes a bit weird. For
> example it calls something that is not a curve a curve.
>>> May I ask why this change was performed?
> After prehashing was eliminated, there was only one algorithm that made
> sense with either, so those were merged.
>>> For JSF (JSON Signature Format) I will stick to the "00" scheme
>>> which also permits use of ed25519ph and friends if needed:
> Beware of implementations that use wildly wrong algorithms.
> And on interactions of Ed25519 and Ed25519ph, they originally interacted
> in harmful ways. Ed25519ph was later changed (in very hacky way) in
> order to fix this (the same mechanism as used to contextualize Ed25519,
> which turned out later to be horrible idea due to API issues it causes).
> And Ed25519ph is weaker than Ed25519. In order to prehash without
> weakening the algorithm, one needs to salt the prehash, which Ed25519ph
> does not do. And lack of salting has been exploited in real world.
>> 8037 was done by CFRG, so probably best to ask there.
> 8037 was done by JOSE. The CFRG part (generic specification of
> EdDSA2) was 8032.
>> I like this aspect of the spec. IMO “alg” as a header was a mistake.
>> By using a generic algorithm header, it forces implementors to
>> associate the specific details in metadata stored with the key, which
>> is much safer.
> Actually a few months ago I came up with idea of having a way to express
> "algorithm determined by the key" in JOSE/COSE.
> - There have been some serious security issues in JWS implementations
>    that have been caused by using completely wrong algorithms.
> - In general, using the same key with multiple algorithms is not
>    cryptographically safe. There can be algorithm pairs which interact
>    badly (for instance, Ed25519 and the original Ed25519ph).
> -Ilari
> _______________________________________________
> jose mailing list