Generally agree with Filip's perspective about appropriate venue and layering.
On Wed, Jun 17, 2026, 3:12 AM Filip Skokan <[email protected]> wrote: > 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] > -- _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you._
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
