RFC 10082 standardizes hybrid post-quantum signatures for S/MIME
News
RFC 10082 standardizes how S/MIME can carry hybrid post-quantum signatures. It defines how to encode and use Composite ML-DSA in Cryptographic Message Syntax (CMS) SignedData. The RFC Editor published it on November 7, 2026, as a Standards Track Proposed Standard. IETF Datatracker event 1243813 records publication at 22:08:03 UTC. The RFC Editor sent the announcement at 22:10:14 UTC. (RFC 10082, publication announcement).
S/MIME already uses CMS SignedData to carry digital signatures. The new RFC gives the software that creates and reads those messages a common way to identify the hybrid algorithm and process its signature. The publication sets no rollout date or deployment deadline. (RFC 8551, Section 2.4.2).
How one S/MIME signature uses two algorithms
Composite ML-DSA pairs the Module-Lattice-Based Digital Signature Algorithm (ML-DSA) with a traditional RSA, ECDSA, or EdDSA signature algorithm. Each defined pairing has one object identifier (OID) and produces one composite signature value. The companion Proposed Standard, published earlier on November 7 UTC, defines the construction, the verification rules, and how X.509 certificates carry the composite public key. (RFC 10073).
A CMS signer that uses the composite puts the pairing's OID in its SignerInfo and stores both signature components in that signer's signature value. The certificate's subject public key uses the corresponding composite algorithm identifier. The verifier uses that pairing to interpret both the public key and the signature. Under Section 3.3 of RFC 10073, the composite verifies only if both the ML-DSA check and the traditional check succeed.
One composite OID identifies two signature components, both of which must verify.
The design gives operators a way to introduce a post-quantum signing algorithm while retaining a traditional component. It fits inside the existing CMS signature fields. The practical distinction is that software still has to recognize the new OID and implement that exact pairing before it can verify the signature.
When checking a certificate, inspect the subject public-key algorithm. The certificate's outer signature algorithm tells you what the issuer used to sign that certificate. A certificate inventory that records only the issuer's signing algorithm will miss whether the subject's public key supports the composite pairing.
A familiar algorithm gives legacy clients no fallback
An older client that understands ECDSA still cannot verify an ML-DSA and ECDSA composite as an ordinary ECDSA-signed email. The composite has its own identifier and the component signs data prepared by the composite construction. A recipient without support for the selected composite cannot validate it.
What RFC 10082 requires in CMS
Sections 2 and 3 define two checks that are easy to miss in an encoder. The Composite ML-DSA AlgorithmIdentifier must omit its parameters field entirely, including an ASN.1 NULL placeholder. In SignerInfo, the CMS digest must match the prehash of the selected composite OID. The signer should also list that digest in the outer SignedData digest set so one-pass verifiers can prepare it.
Choose the digest by OID, since the hash used inside a traditional component can differ from the CMS digest. For example, the ECDSA component in the ML-DSA-87 and P-384 pairing uses SHA-384 internally, while the composite uses SHA-512 as its prehash. Table 1 of RFC 10082 maps each pairing to its CMS digest.
|
|
|
|---|---|---|
ML-DSA-44 | RSA-2048 PSS | SHA-256 |
ML-DSA-65 | ECDSA P-256 | SHA-512 |
ML-DSA-65 | Ed25519 | SHA-512 |
ML-DSA-87 | Ed448 | SHAKE256 (64 bytes) |
Selected digest mappings from RFC 10082, Table 1
The Ed448 pairing is a useful test for libraries with a configurable SHAKE API. For that pairing, RFC 10082 specifies a 64-byte SHAKE256 digest and requires the digest AlgorithmIdentifier parameters to be absent. A test that checks only the digest identifier misses a library configured to produce the wrong output length.
For a concrete encoding, Appendix B uses ML-DSA-65 paired with ECDSA P-256. A decoded CMS message using that pairing should show the following algorithm fields.
Expected SignerInfo fields for the Appendix B pairingtext
signatureAlgorithm.algorithm = 1.3.6.1.5.5.7.6.45 signatureAlgorithm.parameters = absent digestAlgorithm.algorithm = 2.16.840.1.101.3.4.2.3 (SHA-512) digestAlgorithm.parameters = absent
RFC 10082 prefers signed attributes and also specifies the CMS path without them. When attributes are present, the signature covers their Distinguished Encoding Rules (DER) encoding. The recipient still recomputes the digest of the signed content and checks it against the signed message-digest attribute.
Section 5 recommends rejecting a message as invalid CMS if the declared digest differs from the composite prehash. It also allows a verifier to try the pairing's specified prehash for interoperability. That option still requires support for the composite algorithm and successful verification of both signature components.
With signed attributes
The signer includes the content type and message digest among the attributes it signs. The same digest algorithm is used for the content hash and as the composite prehash for the encoded attributes.
Without signed attributes
The composite signs the content octets directly when ordinary CMS rules allow attributes to be omitted. The ASN.1 tag and length of the content field are outside the signature input.
A cryptographically valid composite is one part of accepting a signed message. The ordinary CMS checks still apply, and the recipient still needs to validate the signer's certificate under its S/MIME trust policy.
What to test before a pilot
We'd start with the worked SignedData example in Appendix B of RFC 10082 and the matching certificate in Appendix E of RFC 10073. Supply the certificate separately because the CMS sample leaves it out. That test isolates the CMS encoding and the cryptographic verification before mail clients, gateways, or production certificate trust enter the picture.
From there, the handoff between components matters as much as the signing operation itself. CMS libraries have to parse the identifiers and choose the right digest. Certificate teams need to issue and distribute signing credentials with the matching composite public key. Mail clients and any verifying gateways need to process the same pairing and report what happened.
- Match the credential. Generate fresh composite key material and confirm the certificate's public-key OID matches the CMS signature OID. Exercise certificate lookup and chain validation with the same trust configuration the pilot recipients use.
- Test both components. Verify a known-good sample, then corrupt the ML-DSA and traditional signature components in separate copies. Each copy should fail composite verification. Change the signed content in another copy to check that the CMS content digest catches it.
- Try an unsupported recipient. Send a sample to a client without the composite pairing. Record whether the message remains readable, how the signature is presented, and whether the client distinguishes an unsupported algorithm from a signature it checked and found invalid.
- Use the actual mail route. Send samples through the pilot gateway and open them in the receiving client. Check the signed MIME bytes for changes caused by transformations such as footer insertion. Measure the signed message size against the limits on that route.
If the product supports both detached and opaque S/MIME signatures, test both formats. With a detached signature, the recipient has to reconstruct the verification input from the separate MIME content. If a signature passes a local CMS test and then fails in mail, compare raw message copies captured before and after gateway processing.
Record the client and library versions alongside the OID. A successful test of one pairing says little about another pairing with a different key type or prehash. Separate a CMS decoding failure, a signature verification failure, and a certificate trust failure in the test results so the team responsible can reproduce it.
Where the change stops
RFC 10082 applies to signed content. A signed-only message still provides no confidentiality. The separate FrodoKEM work addresses key encapsulation for CMS encryption, and the CMS signed-attributes best-practices work addresses broader choices about which attributes to sign. Both are separate Internet-Draft efforts. (FrodoKEM encryption draft, CMS signed-attributes draft).
SMTP transport, SPF, DKIM, DMARC, and mailbox-provider requirements are outside the scope of the two RFCs. For the composite signature result, use the receiving S/MIME client or CMS verifier. To check delivery-side authentication separately, send a control message through the same outbound route to our email tester. To check the sending domain's published SPF, DKIM, and DMARC records, use our domain health checker.
Start with one pairing
For a pilot, we'd choose one pairing that the signing stack, certificate issuer, and intended recipients support. Exchange a test message over the real mail route and record what recipients see on both supported and unsupported clients. That gives the team a concrete basis for deciding which recipients can use the new signing format.
Frequency asked questions
It is a published IETF Standards Track RFC at Proposed Standard maturity. The RFC Editor announced it on November 7, 2026 UTC. Product support depends on the implementation, and the publication sets no deployment deadline.
No. A Composite ML-DSA signature with RSA uses a distinct composite OID and verification procedure. Both components must verify under that procedure.
No. It defines conventions for digital signatures in CMS SignedData. Encryption and key establishment use separate CMS mechanisms.
Start with the worked CMS SignedData example in Appendix B of RFC 10082. Use the matching example certificate in Appendix E of RFC 10073, which also provides vectors for the underlying composite algorithms.
