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 <[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#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
[email protected]
https://www.ietf.org/mailman/listinfo/jose
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
