Correct three statements in the 1.0.0 release notes

[zandbelt]

Summary

Three sentences in the 1.0.0 (unreleased) notes that #199 added are wrong about main. A review of the merged text against the source at 0.8.0 and at each pull request found them after the merge; sorry for the second changelog PR in an hour. Three lines change, nothing else.

1. The generated-parameter entry said the check for a caller-supplied "epk" "read it as a string, and "epk" is a JSON object, so it never saw one there". That defect only ever existed on the 0.8.x backport, whose 0.8.1 notes the sentence came from; on main the helper has looked the parameter up as JSON since Refuse a "crit" header and enforce the disjointness of the JWE header locations #188 introduced it (_cjose_jwe_get_json_from_headers, both in the intermediate commit and in 3c153f7). What 0.8.0 actually did on main was silently replace a protected "epk" with the generated one (f2173fd:src/jwe.c:994) and leave one in the shared or a per-recipient header beside it. The entry now says that.

2. The RSA private-member entry gave "imported as a public key" as the outcome for every valueless form. That holds for an empty, null or padding-only member (Refuse an RSA key whose private members are present but carry no value #189, Refuse a private member whose value is base64url padding only #192) but not for a zero one (Refuse a private member whose value is zero #193): it imported as a private key whose export cjose could not read back, which is what Refuse a private member whose value is zero #193's own message and the 0.8.1 section a few lines further down both say. The two sections contradicted each other.

3. The Compatibility paragraph counted "three rules" that refuse input 0.8.0 accepted and missed two: the "oth" refusal of Reject unsupported multi-prime RSA JWKs #190 (0.8.0 knew no such member and imported a multi-prime key as a two-prime one) and Add X25519 and X448 to the ECDH-ES key agreement (RFC 8037 section 3.2) #186's refusal of an "epk" that names a private member (0.8.0 imported it and checked only the curve). It also listed "iv", "tag" and "p2s" as though 0.8.0 had accepted them, when the algorithms that use them are new in this release. The paragraph now names the rules without counting them.

Everything else in #199 was checked at the same time and holds: the copied 0.8.1 section is byte-identical to the 0.8.x branch, and the attributions, identifiers, RFC sections and the README line are accurate.

🤖 Generated with Claude Code