Conceptual feedback on new ECC JEP

[Adam Petcher]

I'm only going to respond to one of your points in detail, see inline below.

For the other points, I don't think we are going to agree. You want the 
implementation to be more interoperable, and I have stated that the 
level of interoperability that you want is not a goal of the JEP. This 
is supposed to be a more secure software ECC implementation, with 
corresponding restrictions on its API. I will be happy with it if the 
API is just functional enough to allow us to use it in SunJSSE, with 
some non-trivial modifications to the SunJSSE code. In the initial 
release of this new provider, it should only be enabled by users who are 
willing to accept this tradeoff between security and 
usability/interoperability, and who are willing to modify existing code 
to make the new provider work.

On 9/7/2018 12:43 PM, Michael StJohns wrote:

>
> Simple way to do this is to extend BigInteger and fix these perceived 
> problems.  You may have to replace/replicate pretty much everything, 
> but as long as it has a BigInteger signature when output, you're good 
> to go.  Actually, do that - clone BigInteger.java as 
> SafeBigInteger.java, have extend java.math.BigInteger and change out 
> the things that bother you. I checked - BigInteger is not a final 
> class so this should work.

Thanks for the suggestion. I agree that this might work, but it would 
greatly increase the scope/effort of this JEP. There might also be other 
solutions that require less effort (e.g. new types of keys/specs that 
hold values as integers, but not BigInteger) that should be considered. 
I've updated the JEP to record this suggestion, and to indicate that it 
is out of scope. We can always enhance the interface/implementation later.