On 5 Jan 2024, at 20:30, Neil Madden <[email protected]> wrote:



On 4 Jan 2024, at 19:37, Orie Steele <[email protected]> wrote:

A similar issue occurs with secp256k1 and ecdsa today.

Some implementations normalize to lower-s (and expect it), others don't.

When you cross test, you get errors in implementations that assume ES256K is always lower S, and it's not... that's for the same ES256K public key (arguably an even worse problem).

The point being that we could fix this by making "ES256K-LS", and we'd have the same problem with older implementations that advertised ES256K.

I'm not familiar with this issue or what "lower S" refers to here. Do you mean some implementations spell the algorithm "Es256K" with a lowercase s?

I’ve just twigged that you’re referring to the s-value in the signature! Presumably some libraries are rejecting non-canonical signature values? I guess that’s an artifact of secp256k1 being the Bitcoin curve and hence a lot of libraries impose additional constraints, for consensus reasons, beyond what is required for signature security. That seems like a straightforward bug in JOSE/COSE implementations that use those libraries.

— Neil
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose

Reply via email to