Conceptual feedback on new ECC JEP

[Adam Petcher]

On 9/19/2018 12:51 PM, Michael StJohns wrote:

> On 9/19/2018 11:45 AM, Adam Petcher wrote:
>> My goal is for the new provider to be at least as interoperable as 
>> PKCS11 providers with non-exportable keys. Do all the PKCS11 
>> providers that you have used allow importing private keys over JCA, 
>> or over some other API? Do you have to put the HSM in some sort of 
>> "import mode" in order for this import to be allowed? Is there any 
>> difference in the way that you can use keys that were loaded over 
>> this API vs keys that were generated on the device (or loaded securely)?
>>
> Again - you seriously want to hang your hat on this?:
>
> 1) Yes.  Over the JCA.  (Umm.. PKCS11 provider is a JCA/JCE provider 
> so of course this works).
>
> 2) No.  In fact, the store operation of the PKCS11 keystore 
> implementation does this just fine.
>
> 3) Depends.  If you generate or load the HSM PKCS11 keys according to 
> the JCA PKCS11 guidance (e.g. with the right set of attributes) using 
> a direct PKCS11 driver, then it's seamless. Otherwise, the Sun PKCS11 
> keystore implementation mostly ignores them as it can't map them 
> properly.    I'd need to check the other two providers I'm aware of, 
> but I think they implement the same scheme as the Sun provider.  
> There's also a scheme for twiddling the attributes as part of the 
> provider configuration, but that's a bit more painful.
>
> See 
> https://docs.oracle.com/javase/7/docs/technotes/guides/security/p11guide.html 
> and Appendix B.
>
>

Thanks for the information. I'm having trouble believing that there is 
no situation in which a PKCS11 provider/token/HSM would reject a key 
that it is asked to import. But this is mostly a detour in the 
discussion. If the API of the new ECC implementation is, in some ways, 
more restrictive than PKCS11 with non-extractable keys, then that is 
acceptable to me.