DSA default algorithm for keytool -genkeypair. Bad choice?
Michael StJohns
mstjohns at comcast.net
Fri Oct 12 16:39:42 UTC 2018
I wasn't thinking so much a re-write as just forking the code and fixing
the things that need to be fixed while leaving the old version to wither
on the vine. The usage page for the "new" program would indicate that
there are no defaults anymore and that users should use the conf file
approach if they want to establish some.
This is more about not having to deal with the backwards compatibility
issues.
Later, Mike
On 10/12/2018 8:24 AM, Weijun Wang wrote:
> 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