RFR: 8360564: Implement JEP 524: PEM Encodings of Cryptographic Objects (Second Preview) [v2]

[Sean Mullan]

On Wed, 17 Sep 2025 01:00:21 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> Hi
>> 
>> Please review the [Second Preview](https://openjdk.org/jeps/8360563) for the PEM API.  The most significant changes from [JEP 470](https://openjdk.org/jeps/470) are:
>> 
>> - Renamed the name of `PEMRecord` class to `PEM`.
>> - Revised the new `encryptKey` methods of the `EncryptedPrivateKeyInfo` class to accept `DEREncodable` objects rather than just `PrivateKey` objects so that cryptographic objects with public keys, i.e., `KeyPair` and `PKCS8EncodedKeySpec`, can also be encrypted.
>> - Enhanced the `PEMEncoder` and `PEMDecoder` classes to support the encryption and decryption of `KeyPair` and `PKCS8EncodedKeySpec` objects.
>> 
>> thanks
>> 
>> Tony
>
> Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision:
> 
>   rework test & commented out code.

src/java.base/share/classes/java/security/PEM.java line 40:

> 38:  * Mail (PEM) data by its type and Base64 content.
> 39:  *
> 40:  * <p> Methods {@link PEMDecoder#decode(String)} and

Suggest rewording as "The {@link PEMDecoder#decode(String)} and {@link PEMDecoder#decode(InputStream)} methods ..."

src/java.base/share/classes/java/security/PEM.java line 42:

> 40:  * <p> Methods {@link PEMDecoder#decode(String)} and
> 41:  * {@link PEMDecoder#decode(InputStream)} return a {@code PEM} object when no
> 42:  * cryptographic object is available to represent the data type.

"is available" sounds a bit odd. Maybe "when the data type cannot be represented by a cryptographic object".

src/java.base/share/classes/java/security/PEM.java line 43:

> 41:  * {@link PEMDecoder#decode(InputStream)} return a {@code PEM} object when no
> 42:  * cryptographic object is available to represent the data type.
> 43:  * If {@code PEM} is desired instead of an available cryptographic object,

"available" again sounds odd, I would just remove that word.

src/java.base/share/classes/java/security/PEM.java line 44:

> 42:  * cryptographic object is available to represent the data type.
> 43:  * If {@code PEM} is desired instead of an available cryptographic object,
> 44:  * decoding methods {@link PEMDecoder#decode(String, Class)} or

s/decoding/the decoding/

src/java.base/share/classes/java/security/PEM.java line 52:

> 50:  *
> 51:  * <p> When constructing a {@code PEM} instance, {@code type} and
> 52:  * {@code content} may not be {@code null}.

s/may not/must not/

src/java.base/share/classes/java/security/PEM.java line 63:

> 61:  * PRIVATE KEY, ENCRYPTED PRIVATE KEY, RSA PRIVATE KEY, or PUBLIC KEY.
> 62:  *
> 63:  * <p> {@code leadingData} may be null if no non-PEM data preceded PEM header

Suggest rewording as "... if there was no data preceding the PEM header ..."

Why do you allow null when there is a ctor that does not have a `leadingData` parameter - is there a reason for this?

src/java.base/share/classes/java/security/PEM.java line 139:

> 137: 
> 138:     /**
> 139:      * Returns a Base64 decoded byte array of {@code content}

Missing period.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2359487443
PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2359520960
PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2359538618
PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2359525172
PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2359552326
PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2359591951
PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2359603695