On Wed, 30 Apr 2025 21:57:39 GMT, Mark Powers <mpow...@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
