Summary

  • RFC 9864 replaces selected polymorphic JOSE and COSE signature identifiers with names that specify the curve and hash choices needed to determine the operation. Ed25519 and Ed448 no longer have to hide behind the family label EdDSA.
  • The repair improves capability negotiation and allow-list precision. It remains only one receipt in a longer chain: registry status, advertised support, key binding, enabled implementation, verifier policy, successful exchange and operational retirement are separate facts.

The capability that was not yet a capability

OAuth metadata, OpenID Connect discovery, WebAuthn and CTAP all rely on algorithm identifiers to say what a participant can do. That arrangement works when a name determines the operation. It fails when the name is a family and the missing parameter must be learned from a key or from an unwritten convention.

RFC 9864 calls the first kind fully specified and the second polymorphic. The distinction is operational, not cosmetic. EdDSA did not tell a negotiating peer whether Ed25519, Ed448 or both were available. In COSE, ES256 named ECDSA and SHA-256 but did not identify a curve. A list of such values could therefore be syntactically accurate and still be insufficient to select a mutually supported operation.

WebAuthn exposed the practical cost. Its profile treated COSE value -8, registered as EdDSA, as Ed25519 with curve value 6. That local restriction made negotiation deterministic, but only by narrowing a shared identifier inside one protocol context. Ed448 could not be inferred from the same declaration. The workaround restored a minimum common meaning while also proving that the original registry name had not carried enough information.

Put the missing choice back in the name

RFC 9864 registers Ed25519 and Ed448 as fully specified JOSE and COSE algorithms, with COSE values -19 and -53. It also gives COSE explicit ECDSA combinations: ESP256 is P-256 with SHA-256; ESP384 is P-384 with SHA-384; ESP512 is P-521 with SHA-512. Four Brainpool combinations receive their own names as well.

The key representation otherwise remains familiar. An Ed25519 key still uses the representation defined by RFC 8037; if an alg member is present, the new value says Ed25519 rather than the polymorphic EdDSA. This is a small change with a useful consequence: the advertised algorithm, the key's intended use and an allow list can refer to the same complete operation without consulting a protocol-specific footnote.

New registry policy follows the same logic. Designated experts for JOSE and COSE are instructed to accept only fully specified algorithm identifiers. A new name must carry the mandatory cryptographic choices rather than outsourcing them to the key, another field or deployment folklore.

Deprecated is a migration signal, not an outage command

The RFC deprecates JOSE EdDSA and the COSE registrations ES256, ES384, ES512 and EdDSA. It also defines the word with care. Deprecated means that a preferred mechanism provides similar functionality and should normally be used for new deployments, unless documented operational or regulatory constraints prevent migration. Prohibited means the identifier and its functionality must not be used.

That distinction prevents a registry update from masquerading as an implementation fact. A deprecated identifier may remain in old credentials, authenticators, libraries, device fleets or archived objects. A verifier that removes it immediately may turn an orderly migration into an availability incident. A producer that keeps emitting it indefinitely may preserve ambiguity and hide the actual curve from capability records. The registry establishes direction; the operator still owns inventory, compatibility, timing, exception evidence and rollback.

The repair is deliberately incomplete

RFC 9864 does not claim to finish every algorithm family. It registers no key-size-specific RSA identifiers. It describes how fully specified ECDH choices would include the curve and KDF but does not register replacements. COSE HSS-LMS remains polymorphic because its identifier does not name the hash function. Encryption is discussed, yet the RFC does not deprecate polymorphic encryption algorithms for which it supplies no replacements.

These exceptions matter more than a clean migration slogan. A control plane cannot transform every old value by rule and then report “fully specified” as a universal state. It needs a typed inventory: replaced identifiers, identifiers already complete, unresolved families, protocol-specific constraints and deliberately retained exceptions. Otherwise the new vocabulary becomes another symbolic layer laid over the same local guesses.

What the identifier can prove

A fully specified value can prove that the record names one curve-and-hash operation rather than a family. It can make discovery, allow lists, conformance tests and detection rules less ambiguous. It can reduce cross-curve mistakes and make policy comparisons reproducible.

It cannot prove that a product contains working code, that an administrator enabled it, that a key is bound to only that algorithm, that a hardware module permits the operation, that a verifier accepts it, or that two peers completed an exchange. RFC 9864 reinforces one part of this boundary by requiring a key to be used with only one algorithm unless multi-algorithm use has been shown safe, and by recommending an algorithm parameter in JWK and COSE keys unless another binding mechanism exists.

The useful operational chain is therefore explicit: registry definition; producer advertisement; key binding; local enablement; verifier allow list; observed negotiation; verification result; application decision. Each layer can fail while the earlier one remains valid.

Sources