[sj26]

Description

An Ed25519 JWK relabelled with crv: "X25519" currently imports as an Ed25519 key and can verify EdDSA tokens. Require crv: "Ed25519" when accessing an OKP signing or verification key, including when constructor parameters override a native key's curve.

Missing curves, X25519, Ed448, and wrong-case curve names now raise JWT::JWKError at key access, not import. A mixed JWKS can therefore contain unrelated X25519 or Ed448 entries without preventing verification with the selected Ed25519 key. Valid native keys and public/private JWKs remain supported. Signatures and cryptographic verification are unchanged: this enforces curve metadata, not a demonstrated signature forgery.

Regression tests cover mixed-JWKS selection, imported and native keys, curve overrides, and decoding. Validation: 34 examples, 0 failures; RuboCop passed. Also tested against the patched ruby-jwt core.

Checklist

• There are tests for the fix or feature added/changed

[anakinj]

Thanks @sj26, the strictness itself looks right to me. RFC 8037 requires crv to be present and says the X25519/X448 subtypes must not be used for signing.

One concern: this raises at import, so a JWKS that has an Ed25519 key next to an X25519 (use: enc) or Ed448 key now fails completely.

Could we do the check where the keys are actually created instead, so we will not create eddsa keys out of the wrong curve keys

A spec with a mixed JWKS would be useful.

[sj26]

Yeah, good ideas! Done.