On Fri, Jun 19, 2026 at 3:44 PM Neil Madden <[email protected]> wrote:
> I mostly agree too, but RFC 8725 already calls out checking for invalid > ECDH curves, which arguably is also a lower-level concern. (Really that’s a > bug in every underlying crypto lib that doesn’t check). > I agree that is a lower-level concern and that the underlying crypto library absolutely should be checking for invalid ECDH curves. But arguably, it shouldn't have been in RFC 8725 and should maybe be removed from the bis document rather than being justification for adding other concerns at this wrong layer. There’s potentially room for some generic statement to be sure to check > what guarantees a cryptographic primitive provides. “Commonly mistaken > assumptions”: signatures may not be unique, public keys may not unique, > public keys are not secret (can be reconstructed from signatures in many > cases), MAC tags may validate under multiple keys, etc. > > It’d be great if underlying libraries eliminated all these issues, but > they don’t and are unlikely to do so any time soon, so maybe we should say > something even if it’s technically the wrong place to? > Some kind of generic statement or general guidance applicable to builders or users of the JW* layer might be very worthwhile. > > — Neil > > On 18 Jun 2026, at 19:20, Brian Campbell <bcampbell= > [email protected]> wrote: > > > 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] > > -- _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]
