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

[Xuelei Fan]

On 11/5/2018 7:13 PM, Weijun Wang wrote:
> Please take a review at the CSR at
> 
>     https://bugs.openjdk.java.net/browse/JDK-8213401
> 
> As for implementation, I intend to report an error when -keyalg is not EC but -curvename is provided. If both -curvename and -keysize are provided, I intend to ignore -keysize no matter if they match or not.
> 
Why not use a strict mode: fail if not match.  It might be misleading if 
ignoring unmatched options.

> Another question: in sun.security.util.CurveDB, we have
> 
>      // Return EC parameters for the specified field size. If there are known
>      // NIST recommended parameters for the given length, they are returned.
>      // Otherwise, if there are multiple matches for the given size, an
>      // arbitrary one is returns.
>      // If no parameters are known, the method returns null.
>      // NOTE that this method returns both prime and binary curves.
>      static NamedCurve lookup(int length) {
>          return lengthMap.get(length);
>      }
> 
> FIPS 186-4 has 2 recommendations (K- and B-) for a binary curve field size. Do we have a choice?
> 
> In fact, CurveDB.java seems to have a bug when adding the curves:
> 
>      add("sect163k1 [NIST K-163]", "1.3.132.0.1", BD,...
>      add("sect163r2 [NIST B-163]", "1.3.132.0.15", BD,... // Another default?
>      add("sect233k1 [NIST K-233]", "1.3.132.0.26", BD,...
>      add("sect233r1 [NIST B-233]", "1.3.132.0.27", B,...
> 
> and now 163 is sect163r2 and 233 is sect233k1.
> 
> I assume we should always prefer the K- one?
> 
TLS 1.3 uses secp256r1/secp384r1/secp521r1, no K- curves.

Do you mean if no -curvename option, there is a need to choose a named 
curve?

Xuelei