RFR 8213400: Support choosing curve name in keytool keypair generation

Weijun Wang weijun.wang at oracle.com
Fri Nov 9 03:30:31 UTC 2018



> On Nov 9, 2018, at 12:28 AM, Adam Petcher <adam.petcher at oracle.com> wrote:
> 
> On 11/8/2018 8:10 AM, Weijun Wang wrote:
> 
>> - CurveDB.java:
>> 
>> -        add("sect163r2 [NIST B-163]", "1.3.132.0.15", BD,
>> +        add("sect163r2 [NIST B-163]", "1.3.132.0.15", B,
>> 
>> All other NIST B-*** curves do not have BD. This should have been a typo.
> 
> I think this will change the default 163-bit curve from sect163r2 to sect163k1. We shouldn't change these defaults without a compelling reason.

I think this is a bug, as there should not be 2 curves with the same field size both having BD.

I can file another bug on this. Maybe it needs it own CSR.

> 
>> 
>> - NamedCurve.java:
>> 
>> A new field commonNames added, which is used by the new GroupName.java test.
> 
> I don't see why this is necessary. The test is using this list of common names to make sure the correct named curve is used. Why not just check the value returned by NamedCurve.getName() against the expected (canonical) name of the curve? Or check the OID?

NamedCurve.getName() returns "secp256r1 [NIST P-256, X9.62 prime256v1]".

I don't want to canonicalize the name (how? returning NamedCurve.getName()?) or use an OID. The test is about making sure the curve used matches the one user specified. What if I am making the same error inside keytool and this canonicalization or string-to-oid method?

In fact, I had wanted to add lines using "alternative names" like "-groupname prime256v1" in the test but later I found out it must be `-groupname "X9.62 prime256v1"` which is not easy to write in the test. (the SecurityTools.keytool() method does not like spaces inside an argument).

You might say since I have already called split(" ")[0] in src/ I can also call it here in a test. But then I still want to have the chance to try out any alternative name later, especially after we think "prime256v1" is better than "X9.62 prime256v1".

Thanks
Max

> 
> 




More information about the security-dev mailing list