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

[Sean Mullan]

On Tue, 10 Jun 2025 14:41:49 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-11 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 when a new key pair is generated or when `KeyFactory::translateKey` is called.
>> 
>> Both the encoding and the expanded format are stored inside a `NamedPKCS8Key` now. When loading from a PKCS #8 key, the expanded format is calculated from the input if it's seed only.
>
> Weijun Wang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:
> 
>  - Merge branch 'master' into 8347938
>  - KeyChoices class
>  - allow expanded to be null
>  - merge
>  - Merge
>  - safer privKeyToPubKey; updated desciptions for the properties; adding braces to if blocks
>  - the fix

test/jdk/sun/security/provider/named/NamedKeys.java line 46:

> 44: 
> 45:         // Create a key using raw bytes
> 46:         var sk = NamedPKCS8Key.internalCreate("SHA", "SHA-256", raw, null);

Can you add a comment somewhere that the algorithms in this test don't mattter? I was wondering why you were using "SHA" here and I had to go look at the `NamedPKCS8Key` code to see that it wasn't testing the "SHA" algorithm.

test/jdk/sun/security/provider/named/NamedKeys.java line 47:

> 45:         // Create a key using raw bytes
> 46:         var sk = NamedPKCS8Key.internalCreate("SHA", "SHA-256", raw, null);
> 47:         var enc = sk.getEncoded().clone();

Why do you clone this?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24969#discussion_r2237621651
PR Review Comment: https://git.openjdk.org/jdk/pull/24969#discussion_r2237617467