Hi, I downloaded JDK 24 EA to play with the new ML-DSA features, and noticed that the `PrivateKey.getEncoded()` produces the expanded-form private key format. However, the industry is aligning behind the seed-form. [1] For instance, BoringSSL removed[2] support for parsing expanded-form private keys, and plans on adding support for reading seed-form private keys instead.
The JDK 24 EA throws away the seed after generating the private keys, so in order to produce seed-form PEMs, I find myself wrapping the `SecureRandom` to capture it, and then wrapping the `PrivateKey` to override the `getEncoded`, both of which are uncomfortable looking hacks. It'd be much preferred if the `PrivateKey.getEncoded` produced the seed-form encoding directly. It looks like the JDK is already perfectly happy to use private keys that do that, at least in the testing I did. Thanks, Chris [1]: https://www.ietf.org/archive/id/draft-ietf-lamps-dilithium-certificates-06.html#name-private-key-format [2]: https://boringssl.googlesource.com/boringssl/+/92a7368bad899b3c81fb99feff33515ee7eb8bb5
