Inline below.
On 11/6/2018 2:18 AM, Weijun Wang wrote:
On Nov 6, 2018, at 1:06 PM, Xuelei Fan wrote:
On 11/5/2018 8:37 PM, Weijun Wang wrote:
On Nov 6, 2018, at 12:12 PM, Xuelei Fan wrote:
On 11/5/2018 7:13 PM, Weijun Wang wrote:
Please take a review at the CSR at
https://bugs.openjd
> Sorry, I haven't had time to look at this in more detail yet. But, let's
> take a step back first. Can you or Matthias explain in more detail why
> this fix is necessary? What are the use cases and motivation?
Hello,
adding paths (or maybe more details) to exception messages just makes
a
Hi,
I have to preface this by saying that this would be my first contribution
to OpenJDK and I'm still learning the ways. Not sure for example if this is
the correct mailing list or if a more generic JDK one would be appropriate.
While working on Hadoop based systems I frequently need to debug Ke
Looks like a reasonable minor enhancement to me.
To contribute, you'll need to sign the OCA first. More information at :
https://openjdk.java.net/contribute/
Regards,
Sean.
On 07/11/18 11:40, Lars Francke wrote:
Hi,
I have to preface this by saying that this would be my first
contribution t
Seán,
thank you!
I've already sent the OCA and am in the process of getting it filed.
According to the docs[0] the next step would be to provide a patch to this
mailing list.
I have to admit that I'm a bit overwhelmed still (having never built
OpenJDK myself) so it'll take a while.
Would this p
One issue that just came to me: How will this work for EdDSA? I think
the CSR could be generalized a bit:
1) Make the first item in the "Solution" more general. Instead of
limiting it to "EC" allow any valid algorithm/curve combination.
2) (Optional) Use -groupname instead of -curvename and cha
On 07/11/18 13:12, Lars Francke wrote:
Seán,
thank you!
I've already sent the OCA and am in the process of getting it filed.
According to the docs[0] the next step would be to provide a patch to
this mailing list.
I have to admit that I'm a bit overwhelmed still (having never built
OpenJDK
I don't think there is any current AlgorithmParameterSpec that allow this for a
KeyPairGenerator. When a curve name is used, keysize is calculated from the
field size.
--Max
> On Nov 7, 2018, at 4:05 PM, Michael StJohns wrote:
>
> Inline below.
>
> On 11/6/2018 2:18 AM, Weijun Wang wrote:
>>
CSR updated. With such a generalized option, I won't recommend -groupname over
-keysize now, although I still intend to print some warning for EC.
Please take a review.
Thanks
Max
> On Nov 7, 2018, at 10:36 PM, Adam Petcher wrote:
>
> One issue that just came to me: How will this work for Ed
Oops, I take this back. The CSR needs more update.
Sorry if you have already start reading it.
Thanks
Max
> On Nov 7, 2018, at 9:27 AM, Weijun Wang wrote:
>
> After some discussion, we decided to cover -keysize and -sigalg in this
> deprecation process too.
>
> Please review the updated CSR
This method returns "secp256r1 [NIST P-256, X9.62 prime256v1]" because that's
how we added it in CurveDB:
add("secp256r1 [NIST P-256, X9.62 prime256v1]", "1.2.840.10045.3.1.7", PD,
"0001",
"0001000
Maybe, the -groupname/-curvename option can be replaced by extending the
existing -keyalg option:
-keyalg secp256r1
Then there is no conflict between the curve/group name and the key alg.
Xuelei
On 11/7/2018 7:48 AM, Weijun Wang wrote:
CSR updated. With such a generalized option, I won't re
On 11/5/18 1:52 PM, Xuelei Fan wrote:
Hi Chris and Sean,
There are a few feedback for the CSR approval. I updated to use
Optional for the returned value. For more details, please
refer to:
https://bugs.openjdk.java.net/browse/JDK-8213161
http://cr.openjdk.java.net/~xuelei/8212261/webr
This sounds a little misleading to me. Alg name and alg params are 2 different
things. This is like asking user to call
KeyPairGenerator.getInstance("secp256r1").
--Max
> On Nov 8, 2018, at 1:47 AM, Xuelei Fan wrote:
>
> Maybe, the -groupname/-curvename option can be replaced by extending the
On 11/7/2018 3:38 PM, Weijun Wang wrote:
This sounds a little misleading to me. Alg name and alg params are 2 different things.
This is like asking user to call KeyPairGenerator.getInstance("secp256r1").
Well, KeyPairGenerator.getInstance("x25519") is a case that JDK 11 has
supported now.
Oth
On 11/7/2018 1:30 PM, Sean Mullan wrote:
https://bugs.openjdk.java.net/browse/JDK-8213161
http://cr.openjdk.java.net/~xuelei/8212261/webrev.03/
I didn't see a test for SecureCacheResponse - is it possible?
JDK does not have the reference implementation of SecureCacheResponse.
You could
Oh, I didn't know that.
To make sure -keyalg matches KeyPairGenerator.getInstance(), I'd like to
support it. If I read the impl correctly, you don't need to initialize it
anymore and if you really want to initialize it the params must be the same.
Currently keytool always calls initialize(). In
In CurveDB.java, we have
add("secp256r1 [NIST P-256, X9.62 prime256v1]", "1.2.840.10045.3.1.7", PD,
"0001",
"0001FFFC",
"5AC635D8AA3A93E7B3EBBD55769886BC651D06B0CC53B0F63
I don't think the underlying provider is ready to support named curves.
Additional RFEs may be required to standardize the names and improve the
underlying provider.
Xuelei
On 11/7/2018 7:05 PM, Weijun Wang wrote:
In CurveDB.java, we have
add("secp256r1 [NIST P-256, X9.62 prime256v1]", "1.2.
19 matches
Mail list logo
