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
