The term on this page
- ML-DSAModule-Lattice-based Digital Signature Algorithm
- the standardised post-quantum replacement for RSA and ECDSA signatures, published as FIPS 204
Also mentioned
ECDSAECDSAElliptic Curve Digital Signature AlgorithmElliptic Curve Digital Signature Algorithm, a widely deployed signature scheme based on elliptic-curve cryptography, offering strong security with compact keys.Read the full entry (new tab), FIPSFIPSFederal Information Processing StandardFederal Information Processing Standards, publicly announced standards developed by NIST for use in U.S. government computer systems, including cryptographic algorithms and modules.Read the full entry (new tab) are defined in the glossary.
Read this first
On 8 October 2026, the IETF JOSE working group published revision 05 of its hybrid signature draft for JSON and CBOR security objects. It defines six profiles that combine ML-DSA with ECDSA or EdDSA and tightens the rules for encoding and verification. The identifiers remain unassigned, every profile is optional for JOSE and marked not recommended for COSE, and the document is still an Internet-Draft rather than a deployment standard.
The new JOSE and COSE composite-signature draft addresses a practical migration question: how can a JSON Web Signature or COSE signature carry a post-quantum component without immediately abandoning the traditional signature systems already deployed? Its answer is one composite algorithm. Both component signatures are generated and verified under the construction defined by the related LAMPS work, while JOSE or COSE presents the pair through one algorithm identifier.
Revision 05 turns encoding choices into verification rules
The October revision is not a new family of algorithms. It is a hardening pass over how the existing proposal is represented and checked. The draft repository records corrected COSE test vectors, deterministic CBOR encoding for those examples, stricter decoding of ECDSA signatures and EC private keys, and expanded security considerations. These changes matter because two implementations can agree on the cryptography and still fail to interoperate, or accept different byte strings, when serialization is underspecified.
- The ML-DSA private component is represented by its 32-byte seed.
- The application context string passed to the composite ML-DSA operation is empty.
- ECDSA signatures use the DER Ecdsa-Sig-Value structure, not the fixed-width JOSE form used by ordinary ES256 or ES384.
- ECDSA private keys include the named-curve parameters and omit the optional public-key field.
- Decoders reject encodings outside the exact forms specified by the draft.
- Replay protection remains an application responsibility through claims such as exp, nbf and jti.
Six profiles cover three ML-DSA parameter sets
| Profile | Post-quantum component | Traditional component | Pre-hash |
|---|---|---|---|
| ML-DSA-44-ES256 | ML-DSA-44 | ECDSA P-256 with SHA-256 | SHA-256 |
| ML-DSA-65-ES256 | ML-DSA-65 | ECDSA P-256 with SHA-256 | SHA-512 |
| ML-DSA-87-ES384 | ML-DSA-87 | ECDSA P-384 with SHA-384 | SHA-512 |
| ML-DSA-44-Ed25519 | ML-DSA-44 | Ed25519 | SHA-512 |
| ML-DSA-65-Ed25519 | ML-DSA-65 | Ed25519 | SHA-512 |
| ML-DSA-87-Ed448 | ML-DSA-87 | Ed448 | SHAKE-256 |
The profiles are not a menu of equivalent security levels. They combine different ML-DSA parameters, curves and pre-hashes, and their encodings inherit the size of both signatures. Teams should start with the required assurance level and protocol budget in the FIPS 204 reference, then use the signature decision guide before treating an algorithm label as a migration plan.
The registry values are placeholders
The JOSE names are requested registrations and the COSE values remain TBD, with draft requests from -54 through -59. Revision 05 marks each JOSE algorithm optional and each COSE algorithm Recommended: No. Private identifiers can support controlled experiments, but they must not be presented as assigned IANA values or interoperable production profiles.
Hybrid does not supply every signature property
The draft's security section draws a boundary that implementers need to preserve. ECDSA combinations are not strongly unforgeable because ECDSA signatures are malleable. Ed25519 and Ed448 combinations provide that property against classical adversaries, but not against a quantum adversary able to break the traditional component. Applications that require strong unforgeability should not assume that adding ML-DSA supplies it automatically.
The document also says a message can have more than one valid composite signature. A signature value, or a hash of the complete JWS or COSE object, therefore cannot serve as a unique business identifier. Deduplication, transaction identity and replay controls must be designed above the signature layer. This is especially important for signed authorization objects, software manifests and long-lived audit records.
Composite and parallel signatures solve different migrations
A composite profile binds two component algorithms behind one identifier and requires both peers to implement the same construction. A protocol that needs independent validation paths, gradual rollout or separate signer policy may be better served by multiple signatures instead. Choose the migration shape before choosing the algorithm name.
What implementers should test now
- Pin revision 05 and the exact experimental identifiers in every test artifact.
- Reject non-canonical DER, an ECPrivateKey carrying the forbidden public-key field, truncated components and reordered components.
- Verify that JOSE and COSE implementations consume the same composite key and signature byte strings.
- Run the corrected COSE examples using deterministic CBOR encoding and compare complete serialized objects.
- Test component failure independently so one accepted signature cannot hide rejection of the other.
- Keep replay, expiry and transaction-identity tests outside the cryptographic verifier.
Those tests belong in both conformance testing and an implementation audit. A successful round trip inside one library proves less than cross-implementation agreement on malformed inputs, exact encodings and both component failures. A migration programme should also record where the relying party cannot yet understand the composite identifier, because compatibility failure is part of the rollout risk.
The useful signal is precision, not deployment readiness
Revision 05 moves the proposal closer to something independent implementations can test by removing ambiguity around keys, ECDSA encoding and COSE examples. It does not make the profiles standards, assign their registry values or establish broad library support. The next signals to watch are working-group progress, IANA assignment, independent test results and whether JOSE and COSE deployments can absorb the combined object sizes without inventing incompatible shortcuts.
References
- draft-ietf-jose-pq-composite-sigs-05, published 8 October 2026, including the six profiles and their security considerations.
- Revision history, recording the October 8 publication of revision 05.
- Draft source history, including the corrected COSE vectors, deterministic encoding and decoding clarifications.
- RFC 9964, the finalized ML-DSA representations for JOSE and COSE that the composite draft builds upon.
- FIPS 204, the normative ML-DSA algorithm and parameter sets.
- RFC 9794, IETF terminology for post-quantum traditional hybrid schemes.
Where this goes next