Hi, I'd like to make a proposal to fix [JDK-8336499](https://bugs.openjdk.org/browse/JDK-8336499).
With the proposed change, a non-sensitive RSA private key is first interpreted as a CRT key. If that fails (e.g. one of the attributes is not available), a second attempt is made to interpret the key as a non-CRT key. In this second attempt, only the required attributes (`CKA_MODULUS` and `CKA_PRIVATE_EXPONENT`) are queried. If this still fails, the key is handled as an opaque key. Most non-sensitive key cases will require a single query, retaining the performance improvement made in [8271566](https://bugs.openjdk.org/browse/JDK-8271566). No changes were made to sensitive keys: they are still handled as opaque keys. No regressions observed in `jdk/sun/security/pkcs11`. As explained in a [JBS comment](https://bugs.openjdk.org/browse/JDK-8336499?focusedId=14690278&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14690278), a regression test for this fix is not easy because the NSS Software Token cannot create non-CRT RSA private keys without a `CKA_PUBLIC_EXPONENT` (as required by the PKCS 11 standard v2.40 and above). A call to `P11RSAKeyFactory::generatePrivate` would fail and the key is never wrapped in a `P11Key` object. A PKCS 11 library implementing a standard previous to 2.40 would be required. With that said, I manually exercised the `asNonCRT` path in the proposed change by using a CRT key and forcing `asCRT` to fail with the debugger. Thanks, Martin.- ------------- Commit messages: - Initial proposal. Changes: https://git.openjdk.org/jdk/pull/20204/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20204&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8336499 Stats: 82 lines in 1 file changed: 47 ins; 13 del; 22 mod Patch: https://git.openjdk.org/jdk/pull/20204.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20204/head:pull/20204 PR: https://git.openjdk.org/jdk/pull/20204
