> The change looks fine. We can enhance the name if we want to support .SF
> parsing later.
>
> Please revise your CSR and get it approved first.
Hi Max, Thanks !
I adjusted the CSR , please approve :
https://bugs.openjdk.java.net/browse/JDK-8207768
Best regards, Matthias
> -Original M
On 9/1/2018 2:03 PM, Michael StJohns wrote:
On 8/23/2018 1:50 PM, Adam Petcher wrote:
It will only support a subset of the API that is supported by the
implementation in SunEC. In particular, it will reject any private
keys with scalar values specified using BigInteger (as in
ECPrivateKeySpec
I've added myself as a reviewer. You might want to set scope to "JDK".
A CSR is approved by the CSR group after you finalize it. First you should
propose it. If you think it's urgent or trivial, you can also fast-track it.
Read https://wiki.openjdk.java.net/display/csr/Main for more details.
Th
Below
On 9/4/2018 8:57 AM, Adam Petcher wrote:
On 9/1/2018 2:03 PM, Michael StJohns wrote:
On 8/23/2018 1:50 PM, Adam Petcher wrote:
It will only support a subset of the API that is supported by the
implementation in SunEC. In particular, it will reject any private
keys with scalar values sp
On 9/4/2018 2:01 PM, Michael StJohns wrote:
Below
*buzz* wrong answer. Sorry. The internal storage of the key can be
anything you want it to be if you want to prevent a non-constant-time
issue for normal calculation. But the import/export of the key really
isn't subject to the cargo cul
I have no finished the full code review. So far, I have a few question
about the struct of the code.
1. XECParameters
I can see the reason to dynamic parameters for something other than
X25519/X448. But for JSSE, currently, only named curves are used. It
would be nice to use the name for the
On 9/4/2018 3:19 PM, Adam Petcher wrote:
I think what you are suggesting is that the implementation should
convert between BigInteger and the internal representation when
necessary. The problem with this approach is that it is too easy to
inadvertently supply a BigInteger to the implementation,
These sun.security.pkcs11.wrapper classes are internal and subject to
changes without notice.
For the time being, maybe we can leave these method intact and add a
comment about calling the new methods which use P11Key argument instead
of the key handle argument.
Regards,
Valerie
On 9/1/2018
I ran javadoc on test/lib so I can learn the useful helper classes, and find
out SecurityTools.java has no javadoc at all.
Please review this change
http://cr.openjdk.java.net/~weijun/8210395/webrev.00/
Thanks
Max
