On Sat, 20 Mar 2021 19:24:45 GMT, SalusaSecondus 
<github.com+829871+salusasecon...@openjdk.org> wrote:

>> 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.

Or, how about changing the scope of 
P11PrivateKey/P11RSAPrivateKey/P11RSAPrivateNonCRTKey to pkg private? This way 
we can take advantage of the info implied by the type of class and avoid the 
potential double failure of querying the attributes.

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

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

Reply via email to