RFR: 8293345: SunPKCS11 provider checks on PKCS11 Mechanism are problematic [v2]
Mark Powers
mpowers at openjdk.org
Tue Apr 9 18:40:10 UTC 2024
On Mon, 8 Apr 2024 19:33:25 GMT, Valerie Peng <valeriep at openjdk.org> wrote:
>> Existing legacy mechanism check disables mechanism(s) when the support is partial, e.g. supports decryption but not encryption, or supports verification but not signing. Some mechanisms can be used for both encryption/decryption and sign/verify such as RSA related ones. If the particular mechanism supports sign/verify/decryption but not encryption, it'd be disabled as a result. Fine tune the legacy mechanism check with the service type, i.e. supports encryption for Cipher, sign for Signature, so the mechanism is disabled based on the service type.
>> For completeness sake, I also added a PKCS11 provider configuration option to control this check (default is true, disable mechanisms with partial support).
>
> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision:
>
> Update to match CSR for disableLegacy -> allowLegacy name change
What about testing?
src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/SunPKCS11.java line 1344:
> 1342: continue;
> 1343: }
> 1344: }
I'm curious why this check was moved down in the file. The only advantage I see is that you have access to `d.type`.
-------------
PR Review: https://git.openjdk.org/jdk/pull/18387#pullrequestreview-1989873086
PR Review Comment: https://git.openjdk.org/jdk/pull/18387#discussion_r1558126501
More information about the security-dev
mailing list