JDK-8233427 : Remove the default keytool -keyalg value
  • Type: CSR
  • Component: security-libs
  • Sub-Component: java.security
  • Priority: P3
  • Status: Closed
  • Resolution: Approved
  • Fix Versions: 14
  • Submitted: 2019-11-02
  • Updated: 2019-11-13
  • Resolved: 2019-11-13
Related Reports
CSR :  
JDK-8214024 - Remove the default keytool -keyalg value
Description
Summary
-------

Remove the default `-keyalg` value for `-genkeypair` and `-genseckey` commands of keytool, so that if user has not explicitly specified one it will be an error.

Problem
-------

The default values (DSA and DES) were deprecated in JDK 12 and it's now time to remove them. In addition, NIST has recently (2019-10-31, https://www.federalregister.gov/documents/2019/10/31/2019-23742/request-for-comments-on-fips-186-5-and-sp-800-186) proposed removing DSA in its FIPS 186-5 draft, claiming that "Industry adoption of DSA was limited" and "recent academic analysis observed that implementations of DSA may be vulnerable to attacks if domain parameters are not properly generated". DES has been considered weak and obsolete for a long time, see https://www.nist.gov/news-events/news/2005/06/nist-withdraws-outdated-data-encryption-standard and https://tools.ietf.org/html/rfc4772.

Solution
--------

Removes the default values.

Specification
-------------

For `keytool -genkeypair` and `keytool -genseckey`, if no `-keyalg` is specified, no key will be generated and `keytool` will terminate with an error showing:

    The -keyalg option must be specified.
Comments
Moving to Approved.
13-11-2019
Thanks for the additional context [~weijun].
13-11-2019
[~darcy] We thought about this last year before we decided to deprecate the default values. Among the other public key algorithms (RSA, RSASSA-PSS, EC), no one seems to be uniformly superior than the others. Cryptography is an evolving technology that toady's preferred algorithms might be obsolete tomorrow, so we don't want to change again later. The main reason we think we can remove the defaults is that DSA and DES are now seldom used in a real productive environment and this change will not be too disruptive. Second, Removing the defaults makes the user specify what they want, perhaps learning about certificates and making an educated choice. Third, while DSA can be used in both signature and key agreement, other public key algorithms do not have this feature and user should not simply accept a default value and hope it can do anything. We talked internally and also asked on security-dev@o.j.n and reached this agreement. We wished we had not created the defaults from the beginning.
11-11-2019
Was updating the default algorithm to a more contemporary value considered to limit behavioral compatibility impact? Moving the request to Provisional (not (yet) Approved).
09-11-2019