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

Anthony Scarpino ascarpino at openjdk.org
Tue Oct 8 19:53:00 UTC 2024


On Tue, 8 Oct 2024 02:28:35 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/pkcs/NamedPKCS8Key.java line 81:
>> 
>>> 79:         } finally {
>>> 80:             val.clear();
>>> 81:         }
>> 
>> The `this.key` is from the `PKCS8Key` class, right? However, looking at the impl of the `PKCS8Key` class, it looks to me that `key` should be equivalent to the `rawBytes` here instead of a DER bytes with OctetString tag.
>
> 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

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21167#discussion_r1792422384


More information about the security-dev mailing list