DSA default algorithm for keytool -genkeypair. Bad choice?

Weijun Wang weijun.wang at oracle.com
Fri Oct 12 12:24:18 UTC 2018


At least, this single annoyance does not deserve a rewrite, the compatibility impact should be quite low.

So far, I've heard these requests related to keytool:

1. Make it GNU-style, say, "keytool -list -keystore cacerts" to "keytool list --keystore=cacerts".

2. Add more functions, say, -importprivatekey.

3. Make some functions as APIs, say, -genkeypair, -certreq.

but still need no rewrite.

--Max



> On Oct 12, 2018, at 12:06 AM, Michael StJohns <mstjohns at comcast.net> wrote:
> 
> Any thought to just deprecating keytool as such and adding a new tool with more modern semantics?    e.g. don't mess with what people are using (except for including a deprecation message), but fork the keytool source tree and do some developments to "ktts" - Key tool - the sequel.   A lot more freedom to rethink the syntax and semantics of key pair and key store generation.
> 
> Mike
> 
> On 10/11/2018 11:44 AM, Sean Mullan wrote:
>> I think if we all really think we are better off in the long run not having defaults, we probably want to do this over 2 releases and give an advance warning that the change is coming. In JDK 12, we could emit a warning, ex:
>> 
>> $ keytool -genkeypair ...
>> Warning: the default keypair alg (DSA) is a legacy algorithm and is no longer recommended. In the next release of the JDK, defaults will be removed and the -keyalg option must be specified.
>> 
>> (that's a bit wordy, but you get the idea)
>> 
>> --Sean
>> 
>> On 10/11/18 9:30 AM, Adam Petcher wrote:
>>> On 10/10/2018 5:05 PM, Anthony Scarpino wrote:
>>> 
>>>> On 10/10/2018 07:42 AM, Weijun Wang wrote:
>>>>> 
>>>>> If not DSA, should RSA be the new default? Or maybe RSASSA-PSS (I wonder if RSASSA-PSS signature can always use legacy RSA keys) or EC? We don't have an option to specify ECCurve in keytool yet (a string -keysize).
>>>>> 
>>>>> --Max
>>>>> 
>>>>> 
>>>> 
>>>> 
>>>> I would rather get rid of the default completely.
>>> 
>>> +1
>>> 
>>> In addition to the usual problems with defaults, there is also the issue that the user doesn't specify how the key pair can be used. The current default produces a key that can only be used with signatures, but if we change the default, then the key may also be used for encryption (RSA) or key agreement (EC). I worry about the problems that can arise if we change the default in a way that increases the capability of the key pair that is produced.
>> 
> 




More information about the security-dev mailing list