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.
