Conceptual feedback on new ECC JEP

[Adam Petcher]

On 9/18/2018 4:24 PM, Michael StJohns wrote:

>
> Adam -
>
> Basically, the JCE is all about plugging in not about the 
> implementations.  If this is truly an EC library, I should be able to 
> get the benefit of your library with very minimal changes - e.g. 
> specifying your provider in the various getInstance() calls.   As it 
> stands, I doubt this will end up in anyone's "must use" category 
> because it will break existing code.

Is this standard of being "truly an EC library" met by PKCS11 providers 
that don't export keys?

>
> You want folks to convince you that interoperability is a significant 
> problem when what we (or at least I) want is for you to convince us 
> that these interop breaks are warranted due to how wonderful your 
> approach is and that they're absolutely necessary due the secret sauce 
> of wonderfulness.  You're not there yet.

I don't agree with this logic. Different providers have different levels 
of interoperability, and this interoperability is a feature that 
requires effort to develop and maintain. I don't want to commit myself 
or this community to this effort unless I/we think it is worthwhile. 
Some of the proposals to increase interoperability for this effort (e.g. 
subclassing BigInteger) would require a significant amount of additional 
effort, and I think this requires justification.

Of course, if you know of a way to have more interoperability without 
reducing assurance or significantly increasing effort, I would love to 
hear about it. For assurance, an important property is that the 
implementation should not branch on secrets after the developer has put 
it in branchless mode (by selecting the branchless provider or by using 
some other interface to switch modes).

>
> As for PKCS11 - there are exportable and non-exportable private keys 
> (e.g. PKCS11 with an accelerator vs an HSM for example).  The 
> exportable ones show up as ECPrivateKeys, the non-exportable ones as 
> PrivateKeys (and I think with an underlying type of PKCS11Key...).  So 
> it follows the model for exportable keys.  And every PKCS11 provider 
> I've used at least has a way of IMPORTING ECPrivateKeys.

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)?