Summary

  • RFC 9964 introduces the generic Algorithm Key Pair type and registers ML-DSA-44, ML-DSA-65 and ML-DSA-87 for JOSE and COSE, so a key and its algorithm parameters can be expressed consistently.
  • Required representation fields and an algorithm registry do not determine key provenance, issuer trust, claim validation, acceptance policy or the operational decision a relying party makes.

There is a tempting mistake in security systems: to let a field that makes an object legible also make it legitimate. An alg value looks decisive. It tells a verifier which family of cryptography to expect; it can constrain how public and private material are represented; and it makes a received object easier to route through software. Yet an algorithm identifier answers a narrow question: what sort of computation is this? It does not answer whether this key should be trusted for this relationship, or whether the signed statement deserves any consequence.

Michael Prorock and Orie Steele’s RFC 9964 puts that narrow job on firm interoperability rails. The IETF Standards Track document specifies ML-DSA keys and signatures for JSON Object Signing and Encryption, JOSE, and CBOR Object Signing and Encryption, COSE. It introduces Algorithm Key Pair, or AKP, as a generic key type for algorithms not limited to the particular algorithms registered by the RFC. An AKP must carry alg and pub; priv holds private information and must not appear in a public key. The structure establishes what an implementation has received and which rules it is expected to apply to the material.

The choice is particularly visible in the private-key treatment. FIPS 204 allows a seed and an expanded private-key expression for ML-DSA. RFC 9964 chooses one compact representation for JOSE and COSE: the priv parameter is a 32-byte seed. That does real work. It removes one otherwise divergent representation, simplifies key handling across the two ecosystems and fixes a boundary that implementations can test. It does not prove who generated the seed, whether it was protected, how the public key was distributed, or whether a relying party should accept anything signed with it.

The RFC also registers ML-DSA-44, ML-DSA-65 and ML-DSA-87. Registration is useful because it connects named parameter choices to JOSE and COSE registries. But registration is not an endorsement engine. A verifier still needs an independent account of the issuer, the key-distribution channel, the subject named by the signed object, the claims that are meaningful in its own context and the policy that turns a valid signature into an allowed operation. A valid alg makes it possible to perform the right cryptographic verification. It does not supply those missing joins.

The document’s own operational cautions support that separation. It notes that ML-DSA keys and signatures are large compared with schemes designed around smaller artifacts, and that bandwidth, memory and processing constraints may make them unsuitable in some settings. This is not a verdict on a named deployment. It is a reminder that format correctness and operational suitability are distinct questions. The standard explicitly places detailed security analysis outside its scope and directs readers to FIPS 204 and RFC 9881.

The most durable reading of Prorock’s co-authored contribution is therefore disciplined rather than heroic. RFC 9964 turns an ambiguous representation problem into explicit fields, a single seed form and registered identifiers. That is a necessary building block for systems that need to exchange ML-DSA material. It leaves trust where it belongs: with the institution or verifier that can name its trust anchors, account for key provenance, evaluate the claim and take responsibility for the decision.

Sources