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.
