RFR: 8263404: RsaPrivateKeySpec is always recognized as RSAPrivateCrtKeySpec in RSAKeyFactory.engineGetKeySpec [v4]

[SalusaSecondus]

On Sat, 20 Mar 2021 18:43:34 GMT, SalusaSecondus <github.com+829871+SalusaSecondus at openjdk.org> wrote:

>> Mike,
>> 
>> From what I can find, if you try to get a spec from a non-extractable key you'll get an `InvalidKeySpecException`.
>> 1. `C_GetAttributeValue`will throw a `PKCS11Exception`
>> 2. The `PKCS11Exception` gets caught in [P11KeyFactory](https://github.com/openjdk/jdk/blob/master/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11KeyFactory.java#L98-L99) which rethrows it as an `InvalidKeySpecException`.
>
> We seem to have a choice and I'm not sure the best way to approach this.
> 
> 1. We trust the properties in `P11Key` and just ask it if the values are both sensitive and extractable. [1]
> 2. But if we already trust P11Key, why not also trust that it properly implements the RSAPrivateKey interfaces [2]. This is the strategy used by the snippet I posted earlier (delegating to `implGetSoftwareFactory()`)
> 3. We don't trust P11Key except to use getKeyId(), this yields the current design where we pull the attributes every time the factory needs them.
> 
> We should probably reduce calls to `C_GetAttributeValue` as they may be very slow. At the least they cross the JNI boundary and at worst they interact with a slow piece of hardware (possibly over a network). The current design will have two calls in a worst case, but is likely to have only one call the vast majority of the time.
> 
> [1] https://github.com/openjdk/jdk/blob/master/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Key.java#L92
> [2] https://github.com/openjdk/jdk/blob/master/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Key.java#L375-L406

P11PrivateKey is private so we cannot check that. Our options to figure out if something is sensitive are:
1. See if it doesn't implement `RSAPrivateKey` (this yields the prior snippet with `implGetSoftwareFactory()`)
2. Try to access the attributes directly from the token (this yields the current solution which we're modifying)
3. Check the value of `p11Key.extractable` (which is package-private and thus visible)

The smallest change would be to keep our strategy as 2. While I like it the least (my favorite is number 1) it has the smallest risk of changing some undocumented behavior on a PKCS#11 device that we're unfamiliar with (and not testing because we may not have the hardware costing tens of thousands of dollars). Option 3 somewhat spits the difference between 1 and 2.

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

PR: https://git.openjdk.java.net/jdk/pull/2949