Thanks @Vladimir Dzhuvinov , it’d be great if this was raised and confirmed on a WG call.
So we have two behaviours for one algorithm name? As a side note, let’s not devise algorithm names like that in the future
Yep, the EdDSA sig alg differs in the hash alg and some params, depending on the key subtype (curve).
So by just looking at “alg” you cannot tell what curve was used. EC DSA in JWS doesn’t have this issue.
This means that to determine the hash alg you need to know the OKP JWK crv value. Which complicates the hash validation :(
It seems this aspect was overlooked.
@John Bradley @mbj No one on the regular call was able to answer here, can you take a look?
SHA-512 sounds right for Ed25519. We plan to discuss this issue in person at IETF in 1.5 weeks in Singapore.
We discussed this on the 25-Nov-19 call. Ed25519 should use SHA-512.
Ed448 logically should use SHAKE256 but it takes a output size parameter. EdDSA signing with Ed448 internally uses SHAKE256 with 114 byte output, so that may be the “right” answer. But apparently some SHAKE256 implementations only support 32 byte (256 bit) outputs, so that’s another possibility. It sounds like this one could use more discussion.
But apparently some SHAKE256 implementations only support 32 byte (256 bit) outputs
E.g. Node.js only added the possibility to specify outputLength for XOF hash functions such as shake256 little over 4 months ago.
Unless there are objections i’d say it is the right answer tho, can we confirm that on the next call with more people in it?
An errata language should clarify which algorithms to use for EdDSA and maybe it wouldn’t hurt to provide an appendix with example outputs. I’ve seen this implemented wrong one too many times in the past. Table follows
Given the access_token value YmJiZTAwYmYtMzgyOC00NzhkLTkyOTItNjJjNDM3MGYzOWIy9sFhvH8K_x8UIHj1osisS57f5DduL the following table represents the at_hash values for a given ID Token signing algorithm (IANA-registered or soon to be at this time)