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.
