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

[Adam Petcher]

On 11/7/2018 8:53 PM, Weijun Wang wrote:

> Oh, I didn't know that.
>
> To make sure -keyalg matches KeyPairGenerator.getInstance(), I'd like to support it. If I read the impl correctly, you don't need to initialize it anymore and if you really want to initialize it the params must be the same. Currently keytool always calls initialize(). In this case, there will be no default -keysize, and initializa() will be not be called if user has not specified one. If user provides -groupname or -keysize just use it and keytool fails if API call fails.

This is correct. If you are using the "X25519" and "X448" algorithm 
name, then there is no need to initialize with parameters, because they 
are decided by the algorithm name. You can still initialize, and 
different providers may be more permissive than others if you try to use 
different parameters than what is specified by the algorithm name. For 
example: KeyPairGenerator.getInstance("X448").initialize(255). SunEC is 
very strict, and will not allow this sort of thing.

X25519/X448 keys can only be used for KeyAgreement, so they aren't 
supported in keytool anyway, right? If this is the case, then you don't 
need to worry about adding any code to keytool for them. Though I expect 
EdDSA to work in a similar way (algorithm names "Ed25519" and "Ed448"). 
Still, I don't know if it is worthwhile to add special code for it. For 
all algorithms, if no -keysize or -groupname is specified, then keytool 
could skip the initialize on the KPG, and the implementation defaults 
(if available) will be used. The hard part is deciding whether to emit a 
warning in this case, and that will probably be algorithm-specific.

>> On Nov 8, 2018, at 8:01 AM, Xuelei Fan <xuelei.fan at oracle.com> wrote:
>>
>> On 11/7/2018 3:38 PM, Weijun Wang wrote:
>>> This sounds a little misleading to me. Alg name and alg params are 2 different things. This is like asking user to call KeyPairGenerator.getInstance("secp256r1").
>> Well, KeyPairGenerator.getInstance("x25519") is a case that JDK 11 has supported now.
>>
>> Otherwise, there is a need to check the conflict of alg name and group name.

This only works because "X25519" (and "X448") is both an algorithm name 
and a parameter spec name. This makes sense for X25519/X448, but not for 
all algorithms.

I don't think there is any need to check for algorithm/group conflicts 
in keytool, because it is checked in the crypto provider already. All 
keytool needs to do is pass down the algorithm name and group name (as a 
NamedParameterSpec/ECGenParameterSpec) and see if it works. If we want 
to support "secp256r1" in -keyalg, then we can accomplish that by adding 
it as an algorithm name for KeyPairGenerator. Though I'm not sure this 
is a good idea.