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

[Weijun Wang]

On Wed, 30 Apr 2025 21:57:39 GMT, Mark Powers <mpowers 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 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);
> }

I'll fix them. Thanks.

> test/jdk/sun/security/provider/named/NamedEdDSA.java line 1:
> 
>> 1: /*
> 
> I didn't expect an EdDSA test in this PQC bug fix.

This is an existing test. It just demonstrates how the `NamedXyz` classes can be used to implement any algorithm that can be configured with a parameter set name.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24969#discussion_r2070185948
PR Review Comment: https://git.openjdk.org/jdk/pull/24969#discussion_r2070185664