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

[Weijun Wang]

On Tue, 23 May 2023 18:55:46 GMT, Martin Balao <mbalao at openjdk.org> wrote:

>> Hmm, so you are aware of a provider whose Key.getEncoded() impl returns the internal key bytes directly? Although the javadoc does NOT state a copy is being returned, it's very likely because an "encoding" is returned. If internal key bytes are returned, it seems bad programming practice, e.g. no protection for internal states/values?
>
> Thanks for your feedback. We've discussed this further and will move forward with the change but Just for the record let me document our conclusions here:
> 
> - This affect non-PBE scenarios and will change [previous JDK behavior](https://git.openjdk.org/jdk/blob/jdk-21%2B23/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java#L190).
> - We have found one type of key in OpenJDK whose getEncoded method does not return a clone [here](https://git.openjdk.org/jdk/blob/jdk-21%2B23/src/jdk.crypto.mscapi/windows/classes/sun/security/mscapi/CPublicKey.java#L86). While we acknowledge that it's unlikely, there can be more in non-OpenJDK security providers.
> - We find that making the callee potentially mutate the arguments without documentation explicitly stating so can be confusing. While the clone pattern is known in Java to overcome limitations in the language and keep object immutability, it's inefficient as copies of objects need to be generated. We hope that the removal of the Security Manager and the untrusted code model provides more incentives for a different approach to this problem in the future.

The SunMSCAPI `getEncoded()` returning an internal cached encoding is a bug. I'll fix it. Thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/12396#discussion_r1202885740