RFR: 8301553: Support Password-Based Cryptography in SunPKCS11 [v3]

[Martin Balao]

On Tue, 23 May 2023 14:00:30 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> We found several more cases of passwords and encoded keys not cleared that were addressed in out Iteration # 2 commit. These cases were both in Java and native code. We still have doubts about the effectiveness and need for these actions, but prefer to have the discussion on a different channel.
>> 
>> We also found that invalid keys (not starting with the name "PBE") passed to PBES2Core::engineInit or P11PBECipher::engineInit were being cleared and this could be unexpected to the caller. This is related to my comment [here](https://github.com/openjdk/jdk/pull/12396#discussion_r1199513839). For these cases, we decided not to invoke ::getEncoded and not to clean. As said, we have concerns about these undocumented mutations to objects passed by argument.
>> 
>> No test regressions observed in jdk/com/sun/crypto/provider or jdk/sun/security/pkcs11.
>
> @martinuy I am adding a CSR requirement for this issue. In this Enhancement, you are adding support for new algorithms in a JCE provider. This type of change requires a CSR as you are adding support for algorithms that can be used by applications and not just inside the JDK, thus it is a type of exported interface of JDK scope. For an example of a similar issue, see [JDK-8274174](https://bugs.openjdk.org/browse/JDK-8274174). The CSR should also include details about any behavioral changes or differences that affect use of the algorithms through the standard JCE APIs.

@seanjmullan @valeriepeng , can you please take a look at the proposed [JDK-8308719](https://bugs.openjdk.org/browse/JDK-8308719) CSR?

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

PR Comment: https://git.openjdk.org/jdk/pull/12396#issuecomment-1563647821