RFR CSR for 8213400: Support choosing curve name in keytool keypair generation

Xuelei Fan xuelei.fan at oracle.com
Thu Nov 8 00:01:53 UTC 2018


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.

Otherwise, there is a need to check the conflict of alg name and group name.

Xuelei

> 
> --Max
> 
>> On Nov 8, 2018, at 1:47 AM, Xuelei Fan <xuelei.fan at oracle.com> wrote:
>>
>> 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 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 <adam.petcher at oracle.com> wrote:
>>>>
>>>> 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 change "curve" to "group" everywhere in the CSR. Then this mechanism can also be used for DSA (with named groups) and other algorithms that use groups that aren't curves.
>>>> Also, see below for a comment about curve ambiguity.
>>>> On 11/6/2018 7:59 PM, Weijun Wang wrote:
>>>>>> Otherwise, there are may be more curve categories. As it is not the recommended option, I may just remove this and the following one sentence.
>>>>>>
>>>>> I'll just leave it there as a FYI since it's not part of the spec.
>>>>
>>>> I agree with Xuelei that this part should be removed. Unless you are planning on implementing this curve selection logic in keytool, then we can't control which curve is selected, and it wholly depends on the behavior of the providers. We can't even guarantee that there is any relationship between "key size" and the field size of the curve. Also, we shouldn't use the word "random" here unless we plan to actually randomize the selection of the curve at runtime (similar to random iteration order for maps/sets). I suggest something more general and vague like:
>>>>
>>>> If only -keysize is specified, an arbitrary curve of the specified size is used
>>>>
> 


More information about the security-dev mailing list