DSA default algorithm for keytool -genkeypair. Bad choice?

[Michael StJohns]

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.
>