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

[Weijun Wang]

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
>