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

[Adam Petcher]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20181107/8609545a/attachment.htm>