> On Dec 12, 2019, at 9:38 AM, Xuelei Fan <[email protected]> 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 <[email protected]> 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
>>>
