Signature Timestamp Support
for J2SE 5.0

Introduction

This document describes the enhancements that have been added in J2SE 5.0 to support signature timestamps. Please send feedback, especially those related to these new features, to java-security@sun.com.

Prior to J2SE 5.0, the signature generated by jarsigner contained no information about w hen the signature was generated. With no other information available, systems/deployers (including users of the Java Plug-in) often based their validity assessment of a signed JAR file on the validity of the signing certificate. When the signing certificate expires, systems/deployers conclude that the signature, and hence, the JAR file, has expired. Because signing certificates typically expire annually, this caused customers significant problems by forcing them to re-sign deployed JAR files annually.

Starting in J2SE 5.0, jarsigner can generate signatures that include a timestamp, thus enabling systems/deployer (including Java Plug-in) to check whether the JAR file was signed while the signing certificate was still valid. In addition, APIs were added in J2SE 5.0 to allow applications to obtain the timestamp information.

The following time-of-signing enhancements and additions are supported in version 5.0 of the Java 2 platform:

Jarsigner Enhancements
Java Plug-in Enhancements
API Enhancements

Jarsigner Enhancements

The jarsigner tool can now generate and store a signature timestamp when signing a JAR file. In addition, jarsigner supports alternative signing mechanisms. This behavior is optional and is controlled by the user at the time of signing through the options described below.

Jarsigner Timestamp Options

The following options were added to the jarsigner tool to support signature timestamps:

-tsa url

If "-tsa http://example.tsa.url" appears on the command line when signing a JAR file then a timestamp is generated for the signature. The URL, http://example.tsa.url, identifies the location of the Time Stamping Authority (TSA). It overrides any URL found via the -tsacert option. The -tsa option does not require the TSA's public key certificate to be present in the keystore.
To generate the timestamp, jarsigner communicates with the TSA using the Time-Stamp Protocol (TSP) defined in RFC 3161. If successful, the timestamp token returned by the TSA is stored along with the signature in the signature block file.

-tsacert alias

If "-tsacert alias" appears on the command line when signing a JAR file then a timestamp is generated for the signature. The alias identifies the TSA's public key certificate in the keystore that is currently in effect. The entry's certificate is examined for a Subject Information Access extension that contains a URL identifying the location of the TSA.
The TSA's public key certificate must be present in the keystore when using -tsacert.

Alternative Signing Options

Specifying an Alternative Signing Mechanism

-altsigner class

Specifies that an alternative signing mechanism be used. The fully-qualified class name identifies a class file that extends the com.sun.jarsigner.ContentSigner abstract class. The path to this class file is defined by the -altsignerpath option. If the -altsigner option is used, jarsigner uses the signing mechanism provided by the specified class. Otherwise, jarsigner uses its default signing mechanism.
For example, to use the signing mechanism provided by a class named com.sun.sun.jarsigner.AuthSigner, use the jarsigner option "-altsigner com.sun.jarsigner.AuthSigner"

Specifying Path to Alternative Signing Mechanism

-altsignerpath classpathlist

Specifies the path to the class file (the class file name is specified with the -altsigner option described above) and any JAR files it depends on. If the class file is in a JAR file, then this specifies the path to that JAR file, as shown in the example below.
An absolute path or a path relative to the current directory may be specified. If classpathlist contains multiple paths or JAR files, they should be separated with a colon (:) on Solaris and a semi-colon (;) on Windows. This option is not necessary if the class is already in the search path.

Example of specifying the path to a jar file that contains the class file:

-altsignerpath /home/user/lib/authsigner.jar

Note that the JAR file name is included.

Example of specifying the path to the jar file that contains the class file:

-altsignerpath /home/user/classes/com/sun/tools/jarsigner/

Note that the JAR file name is omitted.

Java Plug-in Enhancements

In J2SE 5.0, the Java Plug-in was enhanced to check signature timestamps (if available) when validating JAR files. The Java Plug-in will no longer present a dialog when it encounters an expired or revoked certificate when validating a signed jar, provided that the signature timestamp confirms that the signature was generated prior to the expiration or revocation date.

The TSA's certificate must be available from the Plug-in's keystore or certificate stores when the Plug-in is validating a JAR file containing a signature timestamp.

The Plugin reverts to 1.4.x behavior if the signature does not contain a timestamp.

API Enhancements

The security and JAR APIs were enhanced to enable applications to access timestamp information.

Two new classes were added to the java.security package. These classes are CodeSigner, which maintains information associated with a signer, and Timestamp, which represents information associated with a signature timestamp.

New methods were added to the java.security.CodeSource class and java.util.jar.JarEntry class to allow access to this new, optional information.

Please send comments using this Feedback page.

Java Technology

Signature Timestamp Support for J2SE 5.0