Hello all,
This fixes an issue with the TLS 1.3 CertificateRequest message. In
cases where the server side can initially support multiple protocol
versions by the time it issues a CertificateRequest message it collects
the list of supported signature schemes for the signature_algorithms and
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
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
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
On 10/11/18 12:22 AM, Anthony Scarpino wrote:
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.
If we
On 10/10/18 4:52 PM, Michael StJohns 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
