RFR 8234465: Encoded elliptic curve private keys should include the public point

[Weijun Wang]

> On Dec 12, 2019, at 9:38 AM, Xuelei Fan <xuelei.fan at oracle.com> wrote:
> 
> What do you think about the compatibility impact?  Minimal?

I think the major compatibility impact is that ECUtil::decodePoint will throw an exception if the public ECPoint inside is invalid, but I think we shouldn't ignore it. 

Otherwise, the point read can now only be used to write back into a PKCS8 file and not used elsewhere.

> 
> In the ECPrivateKeyImpl.parseKeyBits() implementation, a while() loop is used.  As make it possible to pass publicKey before parameters.  Beside, I would check if the encoded parameter is valid or not.  They're not new, you can leave it as it is.

Yes, this is not complete, and it allows duplicated entries.

Thanks,
Max

> 
> Otherwise, looks good to me.
> 
> Xuelei
> 
> 
> On 12/11/2019 5:21 PM, Weijun Wang wrote:
>> Ping again. This is an enhancement.
>>> On Dec 10, 2019, at 5:45 PM, Weijun Wang <weijun.wang at oracle.com> wrote:
>>> 
>>> Please review the code change at
>>> 
>>>   http://cr.openjdk.java.net/~weijun/8234465/webrev.00/
>>> 
>>> The fix is mostly inside ECPrivateKeyImpl. When an EC keypair is newly generated, a copy of the ECPoint of the public key is put inside the private key. This ECPoint can be stored in a PKCS #8 file. When reading from a PKCS #8 file, it can also be loaded.
>>> 
>>> Since the ECPrivateKey class interface and the ECPrivateKeySpec spec do not have the public ECPoint, an ECPrivateKeyImpl will not have this info when created from these sources. So it's still optional. I haven't tried to calculate it.
>>> 
>>> Thanks,
>>> Max
>>>