On Wed, 17 Jul 2024 16:32:09 GMT, Martin Balao <mba...@openjdk.org> wrote:
>> 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.- > > Martin Balao has updated the pull request incrementally with one additional > commit since the last revision: > > Refactoring and simplification. Session for operations is not needed. > > Co-authored-by: Martin Balao <mba...@redhat.com> > Co-authored-by: Francisco Ferrari Bihurriet <fferr...@redhat.com> I will take a look as well. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20204#issuecomment-2244255132
