When ML-KEM and ML-DSA were introduced in JDK 24, the RFCs defining private key encodings for these algorithms had not been published yet. The drafts at the time, draft-ietf-lamps-kyber-certificates and draft-ietf-lamps-dilithium-certificates, described the private key only as “an opaque byte sequence,” without specifying a concrete format.

Based on that, the JDK 24 implementation adopted the encodings defined in NIST FIPS 203 and 204 — specifically, using the private key output from the ML-KEM.KeyGen function (Section 7.1 of FIPS 203), and the ML-DSA.KeyGen function (Section 5.1 of FIPS 204).

Now that RFC XXX (ML-KEM) and RFC 9881 (ML-DSA) have been published, their private key formats are formally defined as DER-encoded ASN.1 CHOICE types. For example, for ML-KEM-512:

ML-KEM-512-PrivateKey ::= CHOICE {
seed [0] OCTET STRING (SIZE (64)),
expandedKey OCTET STRING (SIZE (1632)),
both SEQUENCE {
seed OCTET STRING (SIZE (64)),
expandedKey OCTET STRING (SIZE (1632))
}
}

Similar structures are defined for ML-KEM-768, ML-KEM-1024, ML-DSA-44, ML-DSA-65, and ML-DSA-87.

The JDK 24 implementation currently uses the second option, `expandedKey OCTET STRING`. To comply with the final RFCs, we need to update our implementation to support the other two CHOICEs as well.