Name: krC82822 Date: 12/09/2000


orig synopsis: "Signatures expire after certificates expire"

java version "1.3.0_01"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0_01)
Java HotSpot(TM) Client VM (build 1.3.0_01, mixed mode)

java version "1.2.2"
Classic VM (build JDK-1.2.2_006, native threads, symcjit)

We have a certificate from Thawte. It is a Netscape Signing Object format
certificate. It expired on Dec 5, 2000, and applets signed with it ceased
working in the Java Plugin version 1.2.2 and 1.3.

It is my impression that a signature signed while a certificate should remain
valid after the certificate expires. This is logical because otherwise a
deployed application (or applet) will stop working at some time that is random
from the customer's point of view; applets such as this become a liability, and
cause potentially costly downtime if noone remembers to resign and redeploy .jar
files.

Additional evidence that a signature should remain valid after its certificate
expires is available at these web sites:

https://www.thawte.com/support/developer/ns.html#certexpire

http://developer.netscape.com/docs/manuals/cms/41/adm_gide/app_sign.htm#1013415
"Will signed objects still be trusted even after their object-signing
certificates have expired?"

Admittedly, there is contrary evidence at the following location (although it
implies but doesn't explicitly say that the signature becomes invalid):

http://www.verisign.com/products/objectsigning/faq.html
"How long is a certificate valid? What happens once it expires?"

Additional information:
We are using Netscape signtool. I've tried with both versions 1.1 and 1.3.
(signtool 1.3 is incompatible with Java2 1.2) And note that we are NOT using
the -z option on signtool, which would have explained the behavior.

The verification works:
c:\jardir>signtool -d \certificate -v myoldjar.jar
archive "myoldjar.jar" has passed crypto verification.

The exception we get under 1.3 is:

java.security.cert.CertificateExpiredException: NotAfter: Tue Dec 05 00:12:16 MST
at sun.security.x509.CertificateValidity.valid(Unknown Source)
at sun.security.x509.X509CertImpl.checkValidity(Unknown Source)
at sun.security.x509.X509CertImpl.checkValidity(Unknown Source)
at sun.plugin.security.TrustDecider.isAllPermissionGranted(Unknown Source)
at sun.plugin.security.PluginClassLoader.getPermissions(Unknown Source)
at java.security.SecureClassLoader.getProtectionDomain(Unknown Source)
at java.security.SecureClassLoader.defineClass(Unknown Source)
at java.net.URLClassLoader.defineClass(Unknown Source)
at java.net.URLClassLoader.access$100(Unknown Source)
at java.net.URLClassLoader$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Unknown Source)
at java.net.URLClassLoader.findClass(Unknown Source)
at sun.applet.AppletClassLoader.findClass(Unknown Source)
at sun.plugin.security.PluginClassLoader.findClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at sun.applet.AppletClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at sun.applet.AppletClassLoader.loadCode(Unknown Source)
at sun.applet.AppletPanel.createApplet(Unknown Source)
at sun.applet.AppletViewer.createApplet(Unknown Source)
at sun.applet.AppletPanel.runLoader(Unknown Source)
at sun.applet.AppletPanel.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
(BTW, I had to type this by hand because copy/paste didn't work from the window.
 But that's a different bug.)

The 1.2.2 exception was much less informative, I don't have that with me.
(Review ID: 113535)
======================================================================