RFR: 8342062: Reformat keytool and jarsigner output for keys with a named parameter set [v3]

[Mark Powers]

On Fri, 13 Dec 2024 15:10:15 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Traditionally, an asymmetric key has a key size. The size is displayed by `keytool` and `jarsigner`, both in informational output and weak-key warnings. However, for the recently added ML-DSA algorithm, key size is not defined.
>> 
>> Thus when an ML-DSA key is created, `keytool` shows
>> 
>> Generating -1 bit ML-DSA-65 key pair...
>> 
>> When the entry is being displayed by `keytool -list -v`, it shows
>> 
>> Subject Public Key Algorithm: -1-bit ML-DSA-65 key
>> 
>> If the algorithm is disabled, `keytool -list` shows
>> 
>> <x> uses a -1-bit ML-DSA-65 key which is considered a security risk...
>> 
>> Furthermore, if a JAR file is signed by ML-DSA, `jarsigner -verify` also shows
>> 
>> Signature algorithm: ML-DSA-65, unknown size
>> 
>> or when the algorithm is disabled, it shows
>> 
>> Signature algorithm: ML-DSA-65, -1-bit key (disabled)
>> The ML-DSA-65 signing key has a keysize of -1 which is considered a security risk.
>> 
>> 
>> With this code change, a key can either has a key size, or characterized by a `NamedParameterSpec`, and the display chooses one of them.
>> 
>> One special case is EC keys, which have both a keysize and a `NamedParameterSpec`. Both are displayed.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   no more combined output

Copyright year needs to be updated in these files:
CheckSignerCertChain.java
DisableCurveTest.java
TimestampCheck.java
Compatibility.java
Test.java
KeyAlg.java

src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Main.java line 1245:

> 1243:             if ((legacyAlg & 8) == 8) {
> 1244:                 warnings.add(String.format(
> 1245:                         rb.getString("The.1.signing.key.has.a.keysize.of.2.which.is.considered.a.security.risk..This.key.size.will.be.disabled.in.a.future.update."),

Just pointing out that replacement by index is the convention for this block of code. Mixing in replacement by variable name seems strange, but maybe that's the future direction of this code. This is just a nit.

-------------

PR Review: https://git.openjdk.org/jdk/pull/22735#pullrequestreview-2537699635
PR Review Comment: https://git.openjdk.org/jdk/pull/22735#discussion_r1907509010