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 this case, there will be no
default -keysize, and initializa() will be not be called if user has not
specified one. If user provides -groupname or -keysize just use it and keytool
fails if API call fails.
Thanks
Max
> On Nov 8, 2018, at 8:01 AM, Xuelei Fan <xuelei....@oracle.com> wrote:
>
> 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....@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.petc...@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
>>>>>
