OpenSSL Position and Plans on Private Key Formats for the ML-KEM and ML-DSA Post-quantum (PQ) Algorithms

The anticipated future arrival of cryptographically relevant quantum computers (CRQCs), that could undermine the algorithms that underlie the currently most widely used public key algorithms (ECDHE, ECDSA, DH and RSA), has led to the development and recent standardisation of new “post-quantum” (PQ) algorithms, that are believed to not be vulnerable to CRQC attack.

Two of the first algorithms standardized are ML-KEM (for key agreement) and ML-DSA (for digital signatures). These algorithms are standardized by NIST in FIPS 203 and FIPS 204. These define the algorithm parameters and how to correctly perform the necessary mathematical operations, but do not define such details as data formats for public and private keys. Those details were left to other standards organisations, such as the IETF.

It was initially expected that the IETF data formats would closely reflect the outputs of the algorithms in FIPS 203 and 204, and various hardware and software implementations have been created on the basis of the NIST specifications and FIPS certificate security requirements.

Unfortunately, the IETF LAMPS working group has moved to specifications that deviate substantially from the private key representations that follow from the NIST documents, electing to represent private keys exclusively via the seed from which the keys are generated, rather than the actual resulting key. The key encoding also deviates from prior practice with other algorithms and entirely forgoes ASN.1 encapsulation of the key, that can be used to encode more than one key representation.

The OASIS PKCS#11 and KMIP working groups are also involved in developing standards involving ML-KEM and ML-DSA, and the position of those working groups is that the seed is an optional, and not required key format in their specifications.

There are already some users who have generated keys based on the NIST specifications, but not retained the seed, which is then not possible to recover. Other users want to be able to use FIPS-certified software and hardware, and it is not at this point clear that the seed format is compatible with FIPS certification. (Key generation from seeds is only a “test” interface, per FIPS 203 and 204).

With this in mind, and in order to best serve our user communities, the OpenSSL project, in conjunction with the developers of the Bouncy Castle and NSS cryptography library, Red Hat, and others, are requesting a change in the direction so far chosen by the IETF, as outlined in the linked PDF, with the text of an email message that has been sent to the IETF “LAMPS” working group that is developing the relevant formats.

The PDF is available here.