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

This is a followup to bug 4396720.  Please see that bug for more information.
The resolution to that bug, though somewhat helpful, is still insufficient.

First of all, I'll list a given: When a certificate expires, it should no longer
generate signatures.

Given that, there is a complicated situation with a .jar file that has a
signature created with a certificate before it expires.  What happens to that
.jar file once the certificate expires?

Prior to bug 4396720, that .jar suddenly becomes invalid when the certificate
expires.  This is bad, because users of the application will be happy until the
certificate expires, and then it will suddenly stop working one day.

So the "fix" applied to solve bug 4396720 as described was to allow anyone who
had already accepted the certificate ("Grant Always") to still be able to use
the application, but everyone else is unable to do so.

This solution is problematic, because the site will then not allow new users to
use the site.  Say the site is run by (making these up) amazon.com or bn.com or
 customer  or some other big important company.  They will be unhappy if they lose new
customers because it took 2 or 3 days to get a new certificate from Thawte or
Verisign.

Additionally, there is evidence from Netscape and Thawte that the signature
should *never* expire.  This would be a much better situation for deploying
applets in the real world.  Without this, deployed applications still have a
time bomb, which is a huge liability.
(Review ID: 126221) 
======================================================================

N/A

It relies on timestamp support in code signing.

  xxxxx@xxxxx   2002-03-01

Duplicate of #4649690.

  xxxxx@xxxxx   2002-03-14