JDK-4500302 : Verification of signed jars does not consider time-of-signing.
  • Type: Enhancement
  • Component: security-libs
  • Sub-Component: java.security
  • Affected Version: 1.4.0
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows_2000
  • CPU: x86
  • Submitted: 2001-09-06
  • Updated: 2017-05-16
  • Resolved: 2003-10-10
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
5.0 tigerFixed
Related Reports
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  

Name: pa48320			Date: 09/06/2001

Verification of signed jars does not consider time-of-signing.  The tools that work with signed jars (such as jarsigner or the Java Plug-in) neither create nor check for time-of-signing information.  (Netscape's signtool purportedly includes time-of-signing information in a jar's signature.)  The result is that valid, correctly-signed jars may be valid one day and, without any modifications, be invalid the next day.  If the signing certificate expires, jars are considered invalid (or at least suspect), even though the jar was signed while the certificate WAS valid, and has not changed since then.  It should be possible to sign jars with time stamping information in such a way that the jars do not expire, merely because the signing certificate expires.  Such a signed jar is completely valid, even after certificate expiration, and should be treated no differently than content signed [correctly] with an unexpired certificate.

As mentioned in 4430673, this creates a large re-deployment and public-relations burden and is completely impractical for real deployment situations.  As mentioned in 4357437, competing and comparable technologies such as Authenticode or Netscape Object Signing provide a time stamping capability that uses the time-of-signing to create signed content that does not expire when the signing certificate expires.  Examination of general signing literature (from RSA, VeriSign, etc.) as well as the certificate and service offerings from CAs clearly show that time stamping and the associated benefits of non-repudiation are expected capabilities of content signing systems.

Thus far, JavaSoft has slowly caved into pressure from irate users by diminishing the severity of errors/warnings for jars signed with expired certificates.  This only hides the problem, and this approach cannot (should not) be carried out to the extreme.

The desired behavior for signed jars should be roughly the following:

During signing, a user may choose to include time-of-signing information.  This timestamp might only be available from root CAs or similar trusted sources?  A jar signed with time-of-signing information would be valid and NEVER expire if
* normal signature verification succeeds
* the signing certificate was valid at the time-of-signing
* the signing certificate was not revoked prior to the time-of-signing
* (optionally) all the jar content was dated prior to the time-of-signing

Signing tools should refuse to sign a jar if the signing certificate is expired, the time-of-signing would be outside validity period of the signing certificate or (optionally) if any of the content to be signed has a timestamp later than the time-of-signing.

Jars without time-of-signing information should be treated as they are now -- usable after expiration if the user is informed of the expiration and chooses to proceed anyway.

Jars with a time-of-signing that does not match the validity period of the signing certificate should be treated as untrusted (if used at all), and the user should have no option to override this behavior.  Optionally, all content timestamps within the jar should pre-date the time-of-signing in order for the jar to be usable.

When (and only when) it is possible to create and use time-of-signing information in signed jars, will the current dialogs for expired jars (which don't include time-of-signing information) be acceptable.  Support for time-of-signing information in signed jars should be provided in all products which deal with signed jars (possibly including APIs).  Particularly, jarsigner, the Java Plug-in and Java Web Start should support time-of-signing.


CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: tiger FIXED IN: tiger INTEGRATED IN: tiger tiger-b24

EVALUATION ###@###.### 2002-03-08 Yes, we recognize the importance of timestamps for signed JARs. PlugIn and Web Start have their own bug categories and are owned by different groups. I've filed rfe 4649690 to track any work needed in PlugIn and rfe 4649703 for Web Start. RFE 4523234 already tracks timestamping support in J2SE. Let's use this rfe (i.e. 4500302) to track enhancements needed in jarsigner. Clearly, this rfe has a dependency on 4523234 which is planned for TIger (pending Tiger team approval, etc.).

WORK AROUND Name: pa48320 Date: 09/06/2001 None. Users see unnecessary warnings and exceptions for previously valid jars which haven't changed. Vendors are forced to re-distribute ALL of their signed jars more often than once per year (the typical duration of signing certificates). ======================================================================