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.
