JDK-8254943 : Update the JAR file spec on EC and RSA signature block types
  • Type: CSR
  • Component: security-libs
  • Sub-Component: jdk.security
  • Priority: P4
  • Status: Closed
  • Resolution: Approved
  • Fix Versions: 17
  • Submitted: 2020-10-16
  • Updated: 2021-06-15
  • Resolved: 2021-04-09
Related Reports
CSR :  
JDK-8254942 - Update the JAR file spec on EC and RSA signature block types
Description
Summary
-------

Add the EC signature block file type to JAR file spec, and renew the definitions of EC and RSA types.

Problem
-------

The JAR file spec only mentions signature block types of RSA and DSA, but we've added EC long long ago. We also recently added support for new signature algorithms like RSASSA-PSS and EdDSA by reusing the existing RSA and EC types.

Solution
--------

See below. This is spec change only. No new code change.

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

In the [JAR File Specification][2], add the ".EC" signature block file extension (in retrospect) and clarify the extension's dependance on private key algorithms.

  [2]: https://download.java.net/java/early_access/jdk15/docs/specs/jar/jar.html

    diff --git a/closed/src/java.base/share/specs/jar/jar.md b/closed/src/java.base/share/specs/jar/jar.md
    --- a/closed/src/java.base/share/specs/jar/jar.md
    +++ b/closed/src/java.base/share/specs/jar/jar.md
    @@ -1,5 +1,5 @@
     ---
    -# Copyright (c) 1993, 2018, Oracle and/or its affiliates. All rights reserved.
    +# Copyright (c) 1993, 2021, Oracle and/or its affiliates. All rights reserved.
     #
     
     title: 'JAR File Specification'
    @@ -166,11 +166,11 @@
     
     The signature file for the JAR file. 'x' stands for the base file name.
     
    --   `x.DSA`
    +-   `x.DSA`, `x.RSA`, or `x.EC`
     
     The signature block file associated with the signature file with the
     same base file name. This file stores the digital signature of the
    -corresponding signature file.
    +corresponding signature file in a PKCS #7 structure.
     
     -   `services/`
     
    @@ -420,6 +420,7 @@
     -   `META-INF/*.SF`
     -   `META-INF/*.DSA`
     -   `META-INF/*.RSA`
    +-   `META-INF/*.EC`
     -   `META-INF/SIG-*`
     
     Note that if such files are located in `META-INF` subdirectories, they
    @@ -597,11 +598,12 @@
     These are binary files not intended to be interpreted by humans.
     
     Digital signature files have the same filenames as the .SF files but
    -different extensions. The extension varies depending on the type of
    -digital signature.
    +different extensions. The extension varies depending on the algorithm
    +of the signer's private key.
     
    --   `.RSA` (PKCS7 signature, SHA-256 + RSA)
    --   `.DSA` (PKCS7 signature, DSA)
    +-   `.RSA` (PKCS7 signature, for RSA or RSASSA-PSS keys)
    +-   `.DSA` (PKCS7 signature, for DSA keys)
    +-   `.EC` (PKCS7 signature, for EC or EdDSA keys)

     Digital signature files for signature algorithms not listed above must
     reside in the `META-INF` directory and have the prefix "`SIG-`". The
Comments
Approving for JDK 17. If backports are wanted for other releases, update the fixVersions field and re-Finalize.
09-04-2021
I updated it to "JDK".
01-04-2021
Yes; if there is not direct change to the Jar API, it seems tenuous to classify this as an SE-scoped change.
01-04-2021
The related API spec only mentions that a JarEntry in a JarFile can be signed, and has not mentioned how the signature is created and where it is stored. The "signature block file" concept only appears in tooldoc for jarsigner and spec for JAR file. In this sense, then maybe the change is an implementation detail and the scope can be "JDK".
30-03-2021
Hmm. Is there some portion of the javadoc for jar handling that should be updated to support this change?
30-03-2021
We don't want to allow all key algorithms to be useable as PKCS #7 block types. In fact, in the recently added support for RSASSA-PSS and EdDSA signatures, we deliberately reuse existing extension types even if the new keys have different getAlgorithm() values. The major reason we add "EC" this time is because it has been actually used for a long time and we will be very cautious on adding any new type in the future. So the whole list is only defined here. As for the scope, the specification is about the JAR file format and not about either the jar tool or jarsigner tool. This is the format behind Java SE APIs in the java.util.jar package (including JarFile, JarEntry, Manifest,...). Therefore we set the scope the "SE".
23-03-2021
Moving to Provisional, not Approved. Is there some security-related spec the jar man page can reference to future-proof this list or is the listing in the jar man page definiative? Note that man spec updates are specs for the tools, but generally not SE specs.
23-03-2021
I think scope should be SE since this is a specification.
19-03-2021