-----Original Message-----
From: Anders Rundgren <[email protected]>
Sent: Saturday, September 19, 2020 11:25 PM
To: Jim Schaad <[email protected]>; [email protected]
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 <[email protected]> On Behalf Of Anders Rundgren
> Sent: Saturday, August 29, 2020 11:58 PM
> To: [email protected]
> 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
> [email protected]
> https://www.ietf.org/mailman/listinfo/jose
>
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
