Refuse an RSA key whose private members are present but carry no value

[zandbelt]

Summary

_cjose_jwk_decode_json_object_base64url_attribute() reports an attribute that is present but empty or null exactly as it reports an absent one: a NULL buffer and a true return. The RSA import takes that at face value for every private member, so

{"kty":"RSA","n":"...","e":"AQAB","d":""}

imports as a public RSA key instead of being refused, and the same holds for "d":null and for p, q, dp, dq and qi in either shape. RFC 7517 gives each of those members a base64url-encoded value, so a key of that shape is malformed and reinterpreting it as a public key hides the error from the caller.

The six decodes now go through a helper that keeps the distinction between an absent member and a valueless one. The required public members need no such guard: a valueless n or e already fails when the key is built, which the test asserts stays true.

This is the third key type to get the rule. The OKP import has made the distinction since it was added, and the EC import gets it in #186, which found this class of bug: an epk of {"kty":"EC",...,"d":""} was imported as public and accepted as an ephemeral key, against RFC 7518 section 4.6.1.1. RSA can never be an epk, so no JWE or JWS rule is involved here, but the import behaviour is the same and is worth settling. Once both have landed the three imports can share this helper; I kept them apart rather than editing code that is in flight.

Testing

• A new jwk suite test builds a random 2048-bit RSA key and, for each of the six private members in both shapes, appends it to the key's public serialization and requires the import to fail with CJOSE_ERR_INVALID_ARG — twelve cases. It also requires the public and the full private serialization of the same key to keep importing. It fails on master with "a d of "" was accepted".
• Full check_cjose with RSA1_5 off and on, valgrind clean over the whole run, clang-format produces no diff.

🤖 Generated with Claude Code