Summary

  • RFC 9964 defines the AKP key type for ML-DSA in JOSE and COSE. It requires alg and pub, excludes priv from public keys, and fixes a common representation that implementations can validate and compare.
  • Although FIPS 204 permits a seed and an expanded private-key expression, RFC 9964 stores only the 32-byte seed in priv. A compact portable encoding is not a statement that one storage location, custodian or signing policy should govern every use of that seed.
  • A valid AKP, thumbprint and signature should be linked to separate local records for custody, requested signing operation, authorization, key lifecycle and verifier acceptance. Otherwise a format decision can quietly become a permission system.

A common representation solves a real interoperability problem

ML-DSA gives JOSE and COSE users a post-quantum signature scheme defined by NIST FIPS 204. But an algorithm alone is not enough for interoperable operation. Systems need to know which key parameters are public, which must remain private, how a verifier recognizes the algorithm, how a public key can be compared across representations, and which bytes are permitted to describe the same signing material.

RFC 9964 answers those questions with Algorithm Key Pair. AKP is a generic key type for algorithms that do not fit the existing registered forms. Its alg parameter is required; pub is required; priv must not appear in a public key. In a JWK, parameters are base64url encoded; in a COSE key, the byte representation can be carried directly. The specification then registers ML-DSA-44, ML-DSA-65 and ML-DSA-87 for both JOSE and COSE and defines the public fields needed for thumbprints.

This is exactly the kind of common layer a protocol should provide. A producer and a verifier can inspect the declared algorithm and public bytes, validate the applicable parameters and derive a public thumbprint without asking a registry operator, platform vendor or security committee to certify each instance. The result is portable evidence about a particular public key and algorithm binding.

The key word is evidence. A thumbprint is a reproducible comparison handle for public parameters. It is not an ownership certificate. It does not prove which team generated the key, which hardware held it, which account asked for a signature or whether a verifier should rely on the signed object in a specific workflow. Treating a deterministic identifier as a universal authority is how a narrow format feature becomes an unaccountable control point.

RFC 9964 chooses a seed; it does not choose a custodian

FIPS 204 describes two expressions relevant to ML-DSA private material: a seed and a private key expanded from that seed. RFC 9964 deliberately accepts only the seed format in AKP priv. It requires a 32-byte seed and intentionally declines to define use of the expanded private-key representation. The stated reason is straightforward: one compact representation across JOSE and COSE reduces storage requirements and makes key management more consistent between the two ecosystems.

That is a design choice about representation, not a claim that a seed is a harmless shorthand. The RFC states that an attacker who obtains either the seed or the private key expanded from it can forge signatures. The two forms demand the same protection. A team that says “we only store the seed” has not avoided custody; it has selected the form from which the signing private key can be generated.

The protocol boundary should therefore remain visible. RFC 9964 can make the seed’s length and encoding checkable. It can say what alg and pub mean and what must be fed to a thumbprint calculation. It cannot determine whether the seed was generated correctly in a particular environment, whether it was copied into a backup, whether a hardware boundary may expand it, whether a delegated service may invoke a signing operation, or whether a recovery procedure has been tested. Those are not gaps for an IETF registration to fill by decree. They are local custody decisions that need local accountability.

The most dangerous operational shortcut is semantic compression. A team sees an AKP with the expected algorithm, verifies a thumbprint and observes a valid ML-DSA signature. It then uses that combination as if it proved all of the following: the expected person or service controlled the signing process; the request was approved; no unauthorized backup exists; the key is still within its rotation period; and the signed payload should change production state. None of those propositions follows merely from the encoding and cryptographic verification.

A seed is sensitive material, not a portable excuse

The seed-only rule offers a useful discipline precisely because it makes a sensitive boundary explicit. The key material no longer has two alternative serializations circulating as if they were interchangeable records. A verifier can expect a single priv form when private material is legitimately present. An implementation can reject a length that is not 256 bits, and the relevant parameter checks can be run before key use.

But a single format is not a single decision-maker. The seed may reside in a protected module, an offline recovery process, a controlled software service or another locally designed arrangement. The specification makes none of those deployments canonical. It also does not make a key record the source of authority over every system that recognizes its thumbprint. An operator may establish a narrow signer capable only of signing one claim type; another may require two approvals for a higher-impact request; a verifier may accept a key only during an explicitly recorded interval.

Those distinctions belong outside the portable encoding because they are consequences of local risk, not invariants needed for JOSE/COSE interoperability.

This is the practical application of Heng Lu’s minimum-specification rule. The common layer should include the deterministic facts that must be shared: an algorithm identifier, public information, private/public separation, valid key parameters and repeatable thumbprint inputs. It should exclude custody arrangements, business roles, access rights, organizational approvals and lifecycle preferences unless they are required for the actual compatibility set. A document that makes a key portable should not silently make its recordkeeper sovereign.

Larger signatures sharpen, rather than erase, the decision boundary

RFC 9964 also records a deployment fact that is easy to treat as mere capacity planning. ML-DSA public keys and signatures are substantially larger than many traditional alternatives. The RFC lists public keys from 1,312 to 2,592 bytes and signatures from 2,420 to 4,627 bytes for the three registered parameters; JOSE’s base64url representation makes a JSON signature larger still. It cautions that constrained bandwidth, memory and processing environments may not suit ML-DSA.

The implication is not that a central body should decide which systems may adopt ML-DSA. It is that adoption is an operational decision with evidence. A participant can test a message path, select a compatible algorithm profile, reject a size it cannot handle, or retain another compatible path during a transition. Publication of an IANA registration is not proof that every dependency has adopted it. A successful verification in one service is not proof that another path has the same limits.

AKP thumbprints help keep public-key comparison stable across JOSE and COSE. They do not solve the surrounding decisions. The thumbprint uses public kty, alg and pub parameters; private material is intentionally absent. That is exactly why it is useful as a public comparison mechanism and exactly why it cannot establish private custody. The record needs a separate answer to a different question: which local control surface allowed this key to be used for this operation at this time?

Keep the signing evidence chain divisible

For an ML-DSA signing workflow, retain at least five distinct records:

  1. A key-registration record identifies the public AKP fields, algorithm, thumbprint and validation result. It says what others can compare.
  2. A custody record identifies the locally approved protection arrangement for the seed or expanded material, including an accountable owner and a recovery or revocation path. It does not publish the sensitive material.
  3. A signing-request record identifies the payload class, requested operation, caller and applicable scope.
  4. An authorization record explains why that request could proceed under local policy and how exceptions were handled.
  5. A verification-and-effect record shows the signature verified with a specific public key and whether a particular relying system accepted, rejected or rolled back the claimed effect.

These records may be closely linked. They should not be merged into a single assertion that a signature exists. A correct AKP representation can coexist with a blocked signing request. A valid signature can coexist with a verifier that declines the payload because it is outside its accepted profile. A compromise response can revoke a key without retroactively erasing the evidence that a prior signature verified. The ability to distinguish those states is what makes a post-quantum migration investigable rather than ceremonial.