<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>One issue that just came to me: How will this work for EdDSA? I
think the CSR could be generalized a bit:</p>
<p>1) Make the first item in the "Solution" more general. Instead of
limiting it to "EC" allow any valid algorithm/curve combination.<br>
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.<br>
</p>
<p>Also, see below for a comment about curve ambiguity.<br>
</p>
<p>On 11/6/2018 7:59 PM, Weijun Wang wrote:<br>
</p>
<blockquote type="cite"
cite="mid:C5FDCD9C-A5A7-4EAA-AD41-D4DB9E60B300@oracle.com">
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">
I'll just leave it there as a FYI since it's not part of the spec.</pre>
</blockquote>
<br>
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:<br>
<br>
If only <code class="prettyprint">-keysize</code> is specified, an
arbitrary curve of the specified size is used<br>
<br>
</body>
</html>