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 >
