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