RFR: 8347938: Switch to latest ML-KEM private key encoding
Weijun Wang
weijun at openjdk.org
Thu May 1 11:57:45 UTC 2025
On Wed, 30 Apr 2025 22:33:24 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 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.
You mean I can use `DerValue.TAG_CONTEXT + 0` instead of 0x80? I can, but yes it's no more readable than the number itself. It's probably all about consistency. If I use `TAG_CONTEXT` here, I might also need to use `tag_OctetString`, `tag_Sequence`.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/24969#discussion_r2070188958
More information about the security-dev
mailing list