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

[Weijun Wang]

> On Nov 6, 2018, at 1:06 PM, Xuelei Fan <xuelei.fan at oracle.com> wrote:
> 
> On 11/5/2018 8:37 PM, Weijun Wang wrote:
>>> On Nov 6, 2018, at 12:12 PM, Xuelei Fan <xuelei.fan at oracle.com> wrote:
>>> 
>>> 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.
>> We can do that, but misleading to what? That we treat -curvename and -keysize the same important?
> If the option "-keysize 256 -curvename sect163k1" work, I may think that the key size if 256 bits.  I want to create a 256 bits sect163k1 EC key, and the tool allows this behavior, so I should get a 256 bits sect163k1 EC key.  Sure, that's incorrect, but I don't know it is incorrect as the tool ignore the key size.  What's the problem of the command, I don't know either unless I clearly understand sect163k1 is not 256 bits.  The next question to me, what's the key size actually is?  256 bits or 163 bits?  which option are used?  It adds more confusing to me.

Well explained. I've updated the CSR and this will be an error.

> 
> We can ignore the -keysize option, but it is complicated to me to use the tool.
> 
>>> 
>>>> 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.
>> There is no ambiguity for prime curves.
>>> 
>>> Do you mean if no -curvename option, there is a need to choose a named curve?
>> ECKeyPairGenerator::initialize(int) will choose one and keytool will use it. I just meant if we have a bug here and if we should be more public on what curve is chosen.
> I see your concerns.
> 
> It might be a potential issue if we use a named curve if no curvename specified.  If the compatibility is not serious, I may suggest supported named curves only, or use arbitrary curves but with a warning.

If people only want prime curves then -keysize still works. A warning is enough since in the CSR I've also said "we recommend".

Thanks
Max

> 
> Xuelei