RFR: 8340327: A common framework to support public key algorithms with standard parameter sets [v10]

[Weijun Wang]

On Tue, 8 Oct 2024 19:49:53 GMT, Anthony Scarpino <ascarpino at 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