Add X25519 and X448 to the ECDH-ES key agreement (RFC 8037 section 3.2)

[zandbelt]

Summary

Adds the X25519 and X448 curves of RFC 8037 section 3.2 to the ECDH-ES key agreement: ECDH-ES, ECDH-ES+A128KW, ECDH-ES+A192KW and ECDH-ES+A256KW now accept OKP keys on those curves next to EC keys. cjose has had the OKP key type with X25519 and X448 since #169 but could only sign with OKP keys; this uses them for what RFC 8037 registered them for.

• What changes. The ephemeral key is generated with the type and curve of the recipient's key and published as an OKP JWK in epk; the Concat KDF, apu, apv and the key sizes are exactly those of RFC 7518, so the four ECDH-ES paths only swap their EC-only calls for two shared helpers, one that makes the ephemeral key and one that checks that the recipient key and epk are of the same type on the same curve. The key agreement in jwk.c performs that check itself as well, so the public cjose_jwk_derive_ecdh_ephemeral_key gains the two curves and refuses mismatched keys with CJOSE_ERR_INVALID_ARG. The Ed25519 and Ed448 signature keys are refused for key agreement everywhere. OpenSSL's exchange already rejects a small-order peer key (the all-zero shared secret of RFC 7748 section 6.1), so no extra check is needed there.
• No new identifiers. The ECDH-ES identifiers stay the polymorphic ones RFC 7518 defines and RFC 9864 section 6.2 explicitly leaves in place; the curve is pinned by the recipient's own key and an epk on any other curve is rejected before the key agreement runs.
• Docs. README rows for the ECDH-ES algorithms and the jwk.h comments of the derive functions, which said "EC key pair".
• Tests. In the jwk suite, the RFC 8037 Appendix A.6 and A.7 examples: the ephemeral key pair and Bob's public key are the RFC's, Bob's private keys come from RFC 7748 section 6 (the examples use its public keys), and the shared secret Z is checked in both directions; plus mismatched-key cases. In the jwe suite, round trips over both curves and all four algorithms with GCM and CBC content encryption, a check that epk is a public OKP key on the recipient's curve, python-jwcrypto vectors for both curves, and negative cases: an Ed25519 key offered for ECDH-ES on encrypt and on decrypt, decrypting an X25519 JWE with an X448 or EC key, and an epk of another type or curve or of the wrong size.

Independent of #184 and #185; whichever lands later needs at most a trivial rebase around adjacent README rows, which I will do.

Testing

• -pedantic -Wall -Werror build and the full check_cjose run (122 checks) with CJOSE_ENABLE_RSA1_5 OFF and ON against OpenSSL 3.5.5.
• valgrind on the jwk and jwe suites: no leaks, no errors.
• The clang-format target produces no diff.

🤖 Generated with Claude Code

[zandbelt]

@TheStormN rebased onto master (3c153f7) and ready for review.

Two conflicts, both resolved by combining rather than choosing a side:

• _cjose_jwe_validate_decrypt_key(): master factored the four ECDH-ES comparisons into _cjose_jwe_alg_is_ecdh_es(), while this PR widens the key type test from kty != CJOSE_JWK_KTY_EC to !_cjose_jwk_is_ecdh_key(jwk) so that X25519 and X448 pass it. Both are kept.
• test/check_jwe.c: the OKP interoperability test and the AES GCM key wrapping one that landed with Refuse a "crit" header and enforce the disjointness of the JWE header locations #188 have the same shape, so they interleaved. I took master's file and re-applied the OKP block rather than untangling the markers; the diff is the same size it was before the rebase.

The interaction worth checking is that master now refuses a header parameter the algorithm produces itself, epk among them: this PR extends the two existing ECDH-ES encryption paths rather than adding new ones, so both places that write epk are still covered. Verified with an X25519 key: the round trip works, a caller-supplied epk is refused, and a crit list is refused.

Full check_cjose with RSA1_5 off and on, valgrind clean, clang-format no diff.

[TheStormN]

The review found a P3 issue. Please check if it is worth fixing in this PR or in a separate one.

Minor P3 conformance note: the new OKP decryption path accepts an epk containing private d, since the check at jwe.c:1364 validates only type and curve. RFC 7518 §4.6.1.1 requires epk to contain only public parameters. This behavior already exists for EC keys and does not affect the derived public-key operation, but strict validation should reject private parameters.

[zandbelt]

Good catch, and fixed here rather than separately (ab737f2), because both key types run through the same check: _cjose_jwk_ecdh_curve_match() compared type and curve for EC and for the OKP curves alike, so one predicate covers the pre-existing EC case and the OKP path this PR adds. Splitting it would have meant writing more code to keep the EC half non-conformant.

_cjose_jwk_ecdh_has_private() reads the has_private flag of either key type, and both ECDH-ES decryption paths refuse an ephemeral key that carries its private part.

One detail worth recording, since it sharpens the "does not affect the derived operation" part of your note: the private epk was not merely tolerated, it was used — the key agreement ran on the key as given and the JWE then failed later with CJOSE_ERR_CRYPTO, from the content authentication, instead of up front with CJOSE_ERR_INVALID_ARG. Both regression tests assert exactly that difference; they fail on the previous commit with code 4 where they now expect code 1. There is one for the OKP curves and one for EC, so the pre-existing behaviour is pinned too.

Full check_cjose with RSA1_5 off and on, valgrind clean, clang-format no diff.

[TheStormN]

I found one remaining P3 issue.
The fix checks the internal has_private flag:
jwe.c:1364-1369
However, EC JWK import treats a present but empty or null "d" member as if it were absent (jwk.c:1979-1999). Therefore an epk such as:

{"kty":"EC","crv":"P-256","x":"...","y":"...","d":""}

is imported as a public key, has_private remains false, and it is accepted. This still violates RFC 7518 §4.6.1.1, which requires epk to contain only public-key parameters.
The added test covers a non-empty private key, but not empty/null "d". The fix should preserve or inspect parameter presence rather than relying only on has_private.

[zandbelt]

You are right, and the has_private flag was the wrong thing to rely on by itself. Fixed in ffd2e9e.

Confirmed first, with the suite's P-256 key, that an epk of {"kty":"EC",...,"d":""} and one with "d":null both imported as public keys and were accepted. The gap is EC-only, and the reason is worth recording: the OKP import this PR adds already refuses a present but valueless d, with (NULL != json_object_get(jwk_json, CJOSE_JWK_D_STR) && NULL == d_buffer), while the EC import, which predates it, never had that check. So the new code was stricter than the old code it sits next to.

Two changes, matching your "preserve or inspect parameter presence":

• the epk header is inspected before the import decides what its members are worth, and a d member is refused whatever it holds, in both ECDH-ES decryption paths. This holds the RFC 7518 section 4.6.1.1 rule at the place the rule is about, independent of what any import makes of a value.
• the EC import treats a present but valueless d as the malformed key it is instead of as a public key, which is the distinction the OKP import already made. A JWK with "d":"" is not a public key and should not be read as one.

Tests cover a private, an empty and a null d for EC and for X25519. Worth noting for the record that the EC cases fail without this commit while the OKP ones already passed, which is the same asymmetry described above.

One thing I did not touch, since it is outside this PR's subject: _cjose_jwk_import_RSA has the same laxness, so {"kty":"RSA","n":...,"e":...,"d":""} also imports as a public key. RSA can never be an epk, so RFC 7518 section 4.6.1.1 is not involved, but it is the same malformed-key-read-as-public shape and the same one-line guard would settle it. Happy to send that as its own PR if you want the three imports to agree.

Full check_cjose with RSA1_5 off and on, clang-format no diff.

[TheStormN]

@zandbelt Yes, please open other PR to address the issue which you noticed.