On Tue, 10 Jun 2025 14:41:49 GMT, Weijun Wang <wei...@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
