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

[Sean Mullan]

On Sat, 20 May 2023 01:20:20 GMT, Martin Balao <mbalao at openjdk.org> wrote:

>> Martin Balao has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
>> 
>>  - Rebase fix after JDK-8306033. Replace called functions with their new names.
>>  - 8301553: Support Password-Based Cryptography in SunPKCS11 (iteration #1)
>>    
>>    Co-authored-by: Francisco Ferrari <fferrari at redhat.com>
>>    Co-authored-by: Martin Balao <mbalao at redhat.com>
>>  - 8301553: Support Password-Based Cryptography in SunPKCS11
>>    
>>    Co-authored-by: Francisco Ferrari <fferrari at redhat.com>
>>    Co-authored-by: Martin Balao <mbalao at redhat.com>
>
> 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.

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

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