Re: [jose] RFC 8037 "alg" quirkiness

-----Original Message-----
From: Anders Rundgren <anders.rundgren.net@gmail.com> 
Sent: Saturday, September 19, 2020 11:25 PM
To: Jim Schaad <ietf@augustcellars.com>; jose@ietf.org
Subject: Re: [jose] RFC 8037 "alg" quirkiness

On 2020-09-20 00:42, Jim Schaad wrote:
> 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());
     }

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

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

> 
> -----Original Message-----
> From: jose <jose-bounces@ietf.org> On Behalf Of Anders Rundgren
> Sent: Saturday, August 29, 2020 11:58 PM
> To: jose@ietf.org
> 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#append
> ix-A.4
> 
> 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:
> https://mobilepki.org/jsf-lab/home
> 
> thanx,
> Anders
> 
> _______________________________________________
> jose mailing list
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose
> 