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).
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?
— Neil Generally agree with Filip's perspective about appropriate venue and layering. 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.
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]
|
