ECDSA malleability was a topic going around JWS libraries a couple months ago, not just for secp256k1, for all ECDSA in JOSE. Userland libraries providing JWS often abstract over lower level crypto libraries (e.g. javascript's jose > Web Cryptography > runtime's backend being e.g. OpenSSL in Node, BoringSSL in Chromium, NSS in Firefox, CommonCrypto in WebKit (i think)). Asking JWS libraries to second-guess the runtime's cryptographic primitives is a stretch and so this would need to trickle down to the level of your OpenSSLs, BoringSSLs, BouncyCastles etc. Much like when CFRG had ed25519 bis on the meeting docket in one of the 2024 meetings ( https://datatracker.ietf.org/doc/slides-121-cfrg-divergences-of-ed25519-in-web-crypto-and-beyond/, https://mailarchive.ietf.org/arch/msg/cfrg/KsJsJ3EUSrNLOsEhEBBFJ8X_SCs/) those libraries maintainers would gladly tighten these but not without a spec.
8725bis is not the right place to tackle this as it goes beyond just JWT, it's JWS, so not even the right working group, and if JWS libraries abstract over runtime's native crypto primitives it's those that need these screws tightened, otherwise we're looking at a split brain problem where the decisively more authoritative lower level crypto says the signature's OK and "some userland library's post-process" says it's not. Daniel wrote that I don't have any preference whether secp256k1 should require canonical > signatures or not. I simply noticed during testing that different > implementations do not agree on the generation and verification. Hence some > implementations generate non-canonical signatures, and others reject them > hence creating some incompatible cases. So it's not necessarily about prohibiting malleability but setting a common baseline? Yes, worth tackling, but I don't think a JWT BCP spec in the OAuth WG is the right place to do so, and without involving CFRG also with questionable downstream effect. S pozdravem, *Filip Skokan* On Wed, 17 Jun 2026 at 11:33, Yaron Sheffer <[email protected]> wrote: > Hi Mike, > > > I'm afraid there's some confusion here. The text you're citing is from RFC > 8812, not 8725 (or the ongoing bis). > > > Moreover, this sounds like a question that would be best shared with CFRG. > > > Thanks, > > Yaron > > > _______________________________________________ > OAuth mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
