Summary

  • RFC 9935 defines seed-only, expanded-key and combined forms for ML-KEM private keys; the ASN.1 tag, not a length guess, identifies the form.
  • When both forms arrive, the recipient should derive the expanded key from the seed and compare the bytes. If it performs that check and they differ, it must reject the package.

The expensive failure in a cryptographic migration is not always a broken algorithm. It can be a successful import whose receipt says less than its operator thinks. RFC 9935, published on the IETF Standards Track in March 2026, makes that problem concrete for ML-KEM keys in X.509 infrastructure.

The public side is deliberately exact. ML-KEM-512, ML-KEM-768 and ML-KEM-1024 have separate NIST object identifiers, and their AlgorithmIdentifier parameters are absent. Their public keys have fixed sizes. If an ML-KEM certificate includes keyUsage, keyEncipherment must be its only asserted use. Those rules let a receiver identify and parse the material. They do not show that a certificate chain was accepted, that policy approved a purpose or that anyone holds the corresponding private material.

The private side contains the more consequential choice. RFC 9935 permits three representations. seed stores 64 bytes from which the expanded decapsulation key and public key can be derived. expandedKey stores the larger decapsulation key. both carries both values for interoperability between systems that retain seeds and systems that consume only expanded keys.

The variants are not inferred from the size of an enclosing blob. The context-specific tag marks a seed, an OCTET STRING marks an expanded key and a SEQUENCE marks the combined form. A parser that observes the tag has established representation. It has not established relationship.

That relationship requires work. For a combined package, RFC 9935 says the recipient should run the defined key-generation function on the seed and compare its expanded output byte-for-byte with the supplied expanded key. A recipient may avoid that computation, but the trade is explicit: it then cannot know whether the two values match. If it does run the check and finds a mismatch, rejection is mandatory.

This creates a useful evidence ladder. “Package parsed” means the structure was intelligible. “Combined form observed” means both fields were present. “Consistency check passed” means one specified derivation reproduced the other field. “Import accepted” is a local decision. None of those records can substitute for the next one.

The expanded key also has an independent boundary. FIPS 203 requires type, length and internal hash checking before ML-KEM decapsulation uses a candidate decapsulation key. It separately describes key-pair checks, including seed consistency when a seed exists and a pair-wise encapsulate/decapsulate test. Even that broader process does not guarantee that the pair was properly produced by the standard key-generation algorithm.

Storage policy matters because the representations are not reversibly interchangeable. Deriving an expanded key from the seed is deterministic. Once an implementation expands the key and discards the seed, it cannot reconstruct the seed from the expanded form. Seed retention therefore preserves compact portability and recovery, while also preserving secret material capable of recreating the key pair. Discarding it reduces one retained representation but closes a future export path.

The certificate does not settle that custody question. RFC 5958 supplies the wider OneAsymmetricKey container, and RFC 9936 shows how CMS can identify an ML-KEM recipient certificate and ciphertext path. Neither proves that the intended system imported a coherent private key, that the right operator controlled it or that a ciphertext was successfully processed.

The operational record should therefore preserve the package fingerprint, declared representation, algorithm identifier, parser result, comparison implementation and version, check result, rejection or acceptance decision, and any subsequent transformation. Private bytes should not enter an ordinary log. The receipt should prove the control without becoming another copy of the secret.

Sources