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

Anthony Scarpino ascarpino at openjdk.org
Mon Oct 20 18:56:17 UTC 2025


On Thu, 9 Oct 2025 05:00:45 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> src/java.base/share/classes/javax/crypto/EncryptedPrivateKeyInfo.java line 565:
>> 
>>> 563:      */
>>> 564:     @PreviewFeature(feature = PreviewFeature.Feature.PEM_API)
>>> 565:     public KeyPair getKeyPair(char[] password) throws GeneralSecurityException {
>> 
>> This should specifically throw an `InvalidKeyException` if decryption fails. I think you want to specify the exact subclasses when it is clearly the right behavior. In this case, the method should always throw `InvalidKeyException` on decryption errors.
>> 
>> Also why generalize it to throw `GeneralSecurityException`? This should throw the same exceptions as `getKeySpec(Key, Provider)` since the params are the same.
>
> Sure, not specifying InvalidKeyException for non-KeyPair return cases in the javadoc is an oversight.  Underneath the code, the `InvalidKeyException` and `NoSuchAlgorithmException` were always thrown, it's the method signature that is different.  Documenting `getKeyPair()` that NSAE and IKE are thrown.  Essentially, I'd replace `@throws GeneralSecurityException ...` with `@throws InvalidKeyException ...`.
> 
> I think it is user-friendly to have GSE  on the method signature. Specifying `NoSuchAlgorithmException` in the method signature I don't think offers value and is purely informative. Since the algorithm is determined by the encoding and cannot be influenced by either getKeyPair method.
> 
> `getKeySpec()` has generalized its exception handling by wrapping `IllegalBlockSizeException` and `BadPaddingException` into `InvalidKeyException`.  The `getKeySpecImpl()` method that all the`getKeySpec()` methods call, wrap `GeneralSecurityException` and `IOException` into `InvalidKeyException`.

I'm changed the throws to NASE and IKE

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2445839787


More information about the security-dev mailing list