I see. The conf file is not smart enough to deal with default values for -sigalg, which can be different from different -keyalg/-keysize values.
Thanks Max > On Oct 13, 2018, at 12:39 AM, Michael StJohns <mstjo...@comcast.net> wrote: > > 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 <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. > >
