SHA-3 and Jarsigner

[jonwltn]

Following on from #293, when using the SHA-3 RSA signature algorithms when signing a JAR in KSE 5.6.1 or with jarsigner 17, produces the following output (Java 11): Signature algorithm: SHA3256withSHA3-256withRSA, 2048-bit key

m  ?     43 Tue Sep 22 17:09:52 PDT 2009 xmltask.properties

 s = signature was verified 
 m = entry is listed in manifest
 k = at least one certificate was found in keystore
 ? = unsigned entry

- Signed by "CN=RSA, O=Example"
   Digest algorithm: SHA-256
   Signature algorithm: SHA3256withSHA3-256withRSA, 2048-bit key

WARNING: Signature is either not parsable or not verifiable, and the jar will be treated as unsigned. For more information, re-run jarsigner with debug enabled (-J-Djava.security.debug=jar).

And the following output for Java 8: Signature algorithm: 2.16.840.1.101.3.4.2.8with2.16.840.1.101.3.4.3.14, 2048-bit key

 m   ?     43 Tue Sep 22 17:09:52 PDT 2009 xmltask.properties

  s = signature was verified 
  m = entry is listed in manifest
  k = at least one certificate was found in keystore
  i = at least one certificate was found in identity scope
  ? = unsigned entry

- Signed by "CN=RSA, O=Example"
    Digest algorithm: SHA-256
    Signature algorithm: 2.16.840.1.101.3.4.2.8withRSA, 2048-bit key
    Warning: nonexistent signed entries: [<<< list of classes here>>>>]

KSE 5.6.1 and jarsigner 17+ operate the same for SHA-3 with RSA signatures, but KSE 5.6.1 and jarsigner 17+ do not operate the same for SHA-2 with RSA signatures. KSE generates signed JARs that produce the user expected output when verifying with jarsigner 11 and 8 (that is, SHA256withRSA).

The two main options that I see are:

1. Update KSE to align with jarsigner 17+ for consistency with jarsigner, that is, remove the workaround added in # 293.
2. Update KSE to add the SHA-3 with RSA signatures to the workaround in # 293.

As a developer, I prefer option 1, but as a user, I can understand the preference for having better display of the signature algorithm.

jarsigner 15+ is needed for verfying any JAR file signed with a SHA-3 based signature algorithm.

For what it's worth, I still think it was the correct decision to always allow the SHA-3 based signature algorithms as an option in KSE 5.6.1 even though there could be compatibility concerns when using an older JDK.

[kaikramer]

Back then when this workaround was introduced, Java 8 was 7 years old and Java 11 only 3 years. And they were the only two LTS versions. But that was almost 5 years ago and at that time KSE still supported everything from Java 8 upwards as its runtime environment. This has changed.

Oracle and the Java Community decided not to backport that functionality to Java 8/11 and I can understand that. Java 8 is too old and there are too many Java versions supported by them. For a small project like KSE it is even more important to draw a line somewhere. Also jarsigner has to work with exactly one Java version, whereas KSE has always supported a wide range of them.

But the main reason why we should remove the workaround is that we should keep these low-level ASN.1 encoding decisions out of KSE. That part is handled very well by Bouncy Castle and every time when we override the BC code, there is a chance that we introduce new bugs or miss future changes.

So, easy decision for option 1.

For what it's worth, I still think it was the correct decision to always allow the SHA-3 based signature algorithms as an option in KSE 5.6.1 even though there could be compatibility concerns when using an older JDK.

Yes, of course.

[jonwltn]

Great! I'll submit a PR.