For one, it makes the user specify what they want, perhaps learning
about certificates and making an educated choice. Secondly, and more
importantly, it would not making it our decisions what is a default
secure algorithm for all of java.
Tony
On 10/10/2018 06:33 PM, Weijun Wang wrote:
I don't know what benefit it brings to a user to remove the default. Except
from forcing DSA users to add a -keyalg option, RSA and EC users will not gain
anything.
--Max
On Oct 11, 2018, at 5:05 AM, Anthony Scarpino <anthony.scarp...@oracle.com>
wrote:
On 10/10/2018 07:42 AM, Weijun Wang wrote:
On Oct 10, 2018, at 7:59 PM, Sean Mullan <sean.mul...@oracle.com> wrote:
There is really no other reason other than DSA keys have been the default
keypairs generated by keytool for a long time, so there are some compatibility
issues we would have to think through before changing it to another algorithm
such as RSA. Weijun might have more insight into that.
Not really. It was the default before I join Sun Microsystems many many years
ago. Maybe it was a NIST standard?
As for compatibility, as long as someone is still using DSA then they might not
be specifying the -keyalg option.
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.
I realize there maybe scripting issues with that. If we made some
documentation guarantees a default algorithm then maybe we are stuck with
having a default and can use a security property. A part of me thinks it would
be foolish for an application to assume a default algorithm and may deserve to
be broken so they can fix it.
Even if we didn't remove defaults from older java version, in future releases
it would be nice to eliminate defaults were possible.
With regard to a replacement, I'd prefer over EC than RSA given a choice. But
either is ok.
Tony
