> On Nov 6, 2018, at 12:12 PM, Xuelei Fan <xuelei....@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?
>
>> 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.
Thanks
Max
>
> Xuelei
