On Tue, 8 Oct 2024 19:49:53 GMT, Anthony Scarpino <ascarp...@openjdk.org> wrote:
>> Yes, `this.key` is the one inside `PKCS8Key`. >> >> Since EdDSA and XDH, the private key has taken this OCTET in OCTET approach. >> My code is identical to the EdDSA code at >> https://github.com/openjdk/jdk/blob/adca97b659d725b0dd320322297dcbd1b443a047/src/java.base/share/classes/sun/security/ec/ed/EdDSAPrivateKeyImpl.java#L50-L64. >> >> In https://datatracker.ietf.org/doc/html/rfc8410#autoid-7 and >> https://www.ietf.org/archive/id/draft-ietf-lamps-kyber-certificates-04.html#name-private-key-format, >> you can see the definitions: >> >> >> OneAsymmetricKey ::= SEQUENCE { >> version Version, >> privateKeyAlgorithm PrivateKeyAlgorithmIdentifier, >> privateKey PrivateKey, >> ... >> } >> >> PrivateKey ::= OCTET STRING >> >> ... CurvePrivateKey object and wrapped by the OCTET STRING of the >> "privateKey" field. >> >> CurvePrivateKey ::= OCTET STRING > > For what it's worth, my [PEM](https://github.com/openjdk/jdk/pull/17543) > changes to > [PKCS8Key.java](https://github.com/openjdk/jdk/pull/17543/files#diff-d4d775f071342d20e524e55883168e018a15f32e0d607518ef3d5f0f76dcdd29) > change `key` to `privKeyMaterial` because `key` doesn't refer to the Key > interface, but binary data @ascarpino Yes I noticed it when I was trying to apply your patch onto mine to see if I can use PEM to encode and decode my new keys. Let's see who gets integrated first. :-) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21167#discussion_r1792482081
