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());
     }

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#appendix-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
> 