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