DSA default algorithm for keytool -genkeypair. Bad choice?

[Anthony Scarpino]

For one, it makes the user specify what they want, perhaps learning 
about certificates and making an educated choice.  Secondly, and more 
importantly, it would not making it our decisions what is a default 
secure algorithm for all of java.

Tony

On 10/10/2018 06:33 PM, Weijun Wang wrote:
> I don't know what benefit it brings to a user to remove the default. Except from forcing DSA users to add a -keyalg option, RSA and EC users will not gain anything.
> 
> --Max
> 
>> On Oct 11, 2018, at 5:05 AM, Anthony Scarpino <anthony.scarpino at oracle.com> wrote:
>>
>> On 10/10/2018 07:42 AM, Weijun Wang wrote:
>>>> On Oct 10, 2018, at 7:59 PM, Sean Mullan <sean.mullan at oracle.com> wrote:
>>>>
>>>> There is really no other reason other than DSA keys have been the default keypairs generated by keytool for a long time, so there are some compatibility issues we would have to think through before changing it to another algorithm such as RSA. Weijun might have more insight into that.
>>> Not really. It was the default before I join Sun Microsystems many many years ago. Maybe it was a NIST standard?
>>> As for compatibility, as long as someone is still using DSA then they might not be specifying the -keyalg option.
>>> 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.
>>
>> I realize there maybe scripting issues with that.  If we made some documentation guarantees a default algorithm then maybe we are stuck with having a default and can use a security property.  A part of me thinks it would be foolish for an application to assume a default algorithm and may deserve to be broken so they can fix it.
>>
>> Even if we didn't remove defaults from older java version, in future releases it would be nice to eliminate defaults were possible.
>>
>> With regard to a replacement, I'd prefer over EC than RSA given a choice.  But either is ok.
>>
>> Tony
>