Subject: Re: [jose] RFC 8037 "alg" quirkiness

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 16 Sep 2020 15:30:43 +0300

On Sun, Aug 30, 2020 at 08:10:17AM +0100, Neil Madden wrote:
> > On 30 Aug 2020, at 07:58, Anders Rundgren <[email-masked]> wrote:
> > 
> > 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. :-)

> > 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:
> > https://tools.ietf.org/html/rfc8037#appendix-A.4
> > 
> > For curiosity reasons I took a peek at the initial draft which has
> > (in my opinion...) a more logical solution:
> > https://tools.ietf.org/html/draft-liusvaara-jose-cfrg-curves-00#appendix-A.4

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:
> > https://mobilepki.org/jsf-lab/home

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

---

From: Anders Rundgren <[email-masked]>
Date: Wed, 16 Sep 2020 15:01:06 +0200

>>> On 30 Aug 2020, at 07:58, Anders Rundgren <[email-masked]> 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 :-)

> You mean JOSE or JWS? Because JSON is a data model and encoding of

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.

Anders

> _______________________________________________
> jose mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/jose
>

---

From: Neil Madden <[email-masked]>
Date: Wed, 16 Sep 2020 14:02:55 +0100

On 16 Sep 2020, at 13:30, Ilari Liusvaara <[email-masked]> wrote:
> […]

Good to know, thanks.

>  badly (for instance, Ed25519 and the original Ed25519ph).

I wrote about this some time ago: https://neilmadden.blog/2018/09/30/key-driven-cryptographic-agility/ <https://neilmadden.blog/2018/09/30/key-driven-cryptographic-agility/> 

JWK already allows associating an algorithm with a key, so I have considered a small draft to deprecate the “alg” header in JOSE entirely. With this WG being disbanded however, there’s not a natural place to do that.

— Neil

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 16 Sep 2020 16:18:49 +0300

On Wed, Sep 16, 2020 at 02:02:55PM +0100, Neil Madden wrote:
> 
> JWK already allows associating an algorithm with a key, so I have
> considered a small draft to deprecate the “alg” header in JOSE
> entirely. With this WG being disbanded however, there’s not a natural
> place to do that.

Maybe ask secdispatch where it should go (I would not be surprised if
the answer turns out to be cose... COSE header 1 (a.k.a. alg) works
pretty much like JOSE alg header).

-Ilari

---

From: Anders Rundgren <[email-masked]>
Date: Thu, 17 Sep 2020 07:02:09 +0200

Apparently the PKIX folks came to a different conclusion:

https://tools.ietf.org/html/rfc8410#section-3

"The same algorithm identifiers are used for identifying a public key,
  a private key, and a signature (for the two EdDSA related OIDs)."

Anders

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 18 Sep 2020 21:01:27 -0700

Hi Anders,

[The quoting seems to have gotten messed up; IIUC the context was the
following]

>   a private key, and a signature (for the two EdDSA related OIDs)."

I'm not seeing how that's inconsistent with one-algorithm-per-key -- you
know from the context in which the OID appears whether you have a
signature, public, or private key, and that context is used to namespace
the following algorithm lookup.  Accordingly, there is no ambiguity as to
what the OID means, in that context.

-Ben

---

From: Anders Rundgren <[email-masked]>
Date: Sat, 19 Sep 2020 06:55:46 +0200

> Hi Anders,

Hi Ben,

First off, this is just a comment to a Request For Comments :),
not a change request.

>>>>      badly (for instance, Ed25519 and the original Ed25519ph).

There is absolutely no disagreement with that but the rationale was as
I understand to make it more difficult to violate the above.  However,
this was not done for "EC" keys so it was effectively another strategy
within the same standard.  That MAY be called "quirk" in the same vein
as the multiple ways of representing binary data in JWS is.

> what the OID means, in that context.

What I was trying to say, is that I find the PKIX naming more logical than
8037.  It is also aligned with Java 15/JCE which doesn't accept "EdDSA" as
a signature algorithm; it only understands Ed25519 and Ed448.

This became obvious in my JWS "remake" (JSF) where I adopted the PKIX
algorithm and key naming scheme:

   {
     "statement": "Hello signed world!",
     "otherProperties": [2e+3, true],
     "signature": {
       "algorithm": "Ed25519",
       "value": "nhYLrEcJV60sEG1RfZGrylL7oVvby1eNRMVzKn-ei93HrXq27e1bqsJpk0rkKg-l9TzTchPFigGt5QbVYirSBw"
     }
   }

Using EdDSA as algorithm in the example above would IMO look a bit strange.

Personally, I would also have considered using "EdDSA" and "ECDH" as "kty"
arguments rather than the somewhat esoteric "OKP" solution, but in the end
it all boils down to the quality of the library or application which should
be prepared for incorrect in-data.

I didn't follow this development when it was active because I wasn't ready
to take on curve25519 and curve448 since Oracle have taken EONS of time
to define the associated API.  It will finally be released this month!

Anders

---

From: Jim Schaad <[email-masked]>
Date: Sat, 19 Sep 2020 08:52:51 -0700

Jumping back to the start.

-----Original Message-----
From: jose <[email-masked]> On Behalf Of Anders Rundgren
Sent: Saturday, August 29, 2020 11:58 PM
To: [email-masked]
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:
https://tools.ietf.org/html/rfc8037#appendix-A.4

[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.

Jim

For curiosity reasons I took a peek at the initial draft which has (in my
opinion...) a more logical solution:
https://tools.ietf.org/html/draft-liusvaara-jose-cfrg-curves-00#appendix-A.4

For JSF (JSON Signature Format) I will stick to the "00" scheme which also
permits use of ed25519ph and friends if needed:
https://mobilepki.org/jsf-lab/home

thanx,
Anders

---

From: Anders Rundgren <[email-masked]>
Date: Sat, 19 Sep 2020 18:11:58 +0200

> of options down to just those that are fixed by the curve.

Hi Jim,

It may be just me but I prefer the algorithm/key identifier solution you selected for PKIX:
https://tools.ietf.org/html/rfc8410#section-3
It is as you say not identical to the JOSE ECDSA solution, but it is (IMO then...) "closer".

Oracle also adopted the PKIX notation for JCE and so did yours truly for JSF.

Anyway, the crypto world seems to be full of quirks like two different ways
of representing ECDSA signatures.

Nobody died.  We can safely drop this thread :)

Anders

---

From: Jim Schaad <[email-masked]>
Date: Sat, 19 Sep 2020 15:42:38 -0700

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

Jim

thanx,
Anders

---

From: Anders Rundgren <[email-masked]>
Date: Sun, 20 Sep 2020 08:24:56 +0200

> Jumping back to the start.

It seems that your mail system generates duplicates.

FWIW, here is how the quirk manifests itself in my JOSE library:

     JSONObjectWriter setSignatureAlgorithm(JSONObjectWriter joseObject,
                                            SignatureAlgorithms signatureAlgorithm) {
         return joseObject.setString("alg",
                                     signatureAlgorithm.isOkp() ?
              "EdDSA" : signatureAlgorithm.getAlgorithmId());
     }

Presumably few cryptographic API's accept "EdDSA" as a signature algorithm.

You could indeed have used "EdDSA" as signature algorithm in RFC 8410 but
you did not and IMO you did the right choice.

Anyway, navigating in crypto-land is often a bit challenging:
https://mail.openjdk.java.net/pipermail/security-dev/2020-August/022348.html

I've made my point, nothing more to add on my side :)

Anders

---

From: Jim Schaad <[email-masked]>
Date: Sun, 20 Sep 2020 00:07:27 -0700

-----Original Message-----
From: Anders Rundgren <[email-masked]> 
Sent: Saturday, September 19, 2020 11:25 PM
To: Jim Schaad <[email-masked]>; [email-masked]
Subject: Re: [jose] RFC 8037 "alg" quirkiness

[JLS] This draft will soon render this code incorrect.  https://datatracker.ietf.org/doc/draft-ietf-lwig-curve-representations/

You could indeed have used "EdDSA" as signature algorithm in RFC 8410 but you did not and IMO you did the right choice.

Anders

> 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
> For JSF (JSON Signature Format) I will stick to the "00" scheme which 
> also permits use of ed25519ph and friends if needed:

---

From: Anders Rundgren <[email-masked]>
Date: Sun, 20 Sep 2020 10:51:49 +0200

On 2020-09-20 09:07, Jim Schaad wrote:
<snip>
> [JLS] This draft will soon render this code incorrect.  https://datatracker.ietf.org/doc/draft-ietf-lwig-curve-representations/

Sure, note though that the draft (in contrast to RFC 8037), defines key-specific "alg" parameters.

Anders