Conceptual feedback on new ECC JEP

[Adam Petcher]

On 9/25/2018 11:15 AM, Xuelei Fan wrote:

> I did not follow the discussion.  But it does not sound right to me to 
> have an application to be provider dependent (#3).

There will be nothing provider-dependent in the TLS implementation. The 
point of #3 is to say that we should test the TLS implementation to 
ensure that it will work with either "EC" provider. The only required 
changes to TLS code will be using PKCS8 private keys instead of 
BigInteger private keys.

>
> I was not confident that a new provider instead of updating the 
> existing provider is a good idea.  It might be a significant effort to 
> update existing provider.  However, if we don't do that, the cost to 
> use the new provider is not minimal.
>
> As we discussed previous, lacking interop could face significant 
> issues and result in complicated coding in practice.  Thinking about 
> SunPKCS11 and SunMSCAPI provider, and how many trouble we have had for 
> them, and how many workaround we have patched for them.
>
> Unless it is not possible to have an interop-able implementation, I 
> would suggest take more time to have an interop-able design and impl.
>
> Is it possible to have an interop-able impl?  If it is possible, how 
> much effort will it take?

Yes, it is possible, at the expense of some assurance related to 
security against side-channel attacks. This interoperable implementation 
will be available by default in SunEC. A higher-assurance form of the 
same implementation will be available in the new provider. The 
additional effort required to put this implementation in both providers 
is expected to be relatively small.