Verification of signed jars does not consider time-of-signing.

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.

======================================================================