RFR: 8347938: Switch to latest ML-KEM private key encoding

[Mark Powers]

On Wed, 30 Apr 2025 15:43:31 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> The private key encoding formats of ML-KEM and ML-DSA are updated to match the latest IETF drafts at: https://datatracker.ietf.org/doc/html/draft-ietf-lamps-dilithium-certificates-08 and https://datatracker.ietf.org/doc/html/draft-ietf-lamps-kyber-certificates-10. New security/system properties are introduced to determine which CHOICE a private key is encoded.
> 
> Both the encoding and the expanded format are stored inside a `NamedPKCS8Key` now. When loading from a PKCS #8 key, the expanded format is either calculated or copied from the input.

src/java.base/share/classes/sun/security/util/KeyUtil.java line 506:

> 504:                 if (seed == null) return null;
> 505:                 skOctets = new byte[seed.length + 2];
> 506:                 skOctets[0] = (byte)0x80;

Is there any value in using the DerValue class to put a name on these constants? I think what you have is easy enough to read.

src/java.base/share/classes/sun/security/util/KeyUtil.java line 511:

> 509:             }
> 510:             case "expandedkey" -> {
> 511:                 if (expanded == null) expanded = expand.apply(pname, seed);

This looks good to me, but the style guideline is

if (expanded == null) {
    expanded = expand.apply(pname, seed);
}

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24969#discussion_r2069573063
PR Review Comment: https://git.openjdk.org/jdk/pull/24969#discussion_r2069531486