Name: gm110360			Date: 08/14/2002


FULL PRODUCT VERSION :
Java(TM) Plug-in: Version 1.3.1
Using JRE version 1.3.1 Java HotSpot(TM) Client VM

FULL OPERATING SYSTEM VERSION :

*ALL*

ADDITIONAL OPERATING SYSTEMS :

*ALL*



A DESCRIPTION OF THE PROBLEM :
I write software for a wide variety of companies, and have
worked with IBM in the past.  Our organization has
determined there is a limitation in the Java Sandbox model
that prevents us from deploying the plugin as we would like
in an enterprise "server-farm" environment.

  To start out, here's what we want to do -- we want to have
a "permission-granted" applet installed on a customer's
servers, that can run indefinitely.  The needs of European
banks, for instance, require that software updates be done
very infrequently, for instance, once every 2 years.  This
sort of update cycle, combined with the dedication of the
customer to keep "working" configurations, prohibits the
traditional VeriSign/THAWTE Signed applet from working well
in practice.

Case in point:

Large software firm ABC releases software DEF, and by the
time it through OEM test and installed at the customer's
site, the software is over a year old. The application in
question has signed jar files, so that it can deliver
powerful applets to various client machines.
However, given this model, the signed applets expire within
a very short time after they install.  The customer's next
software update Window is a year down the road, and they
become very frustrated that the software they just
installed now has expired.

So, what we want is this -- we want, in however a blatant
manner (flashing lights, etc) the ability to have a self-
signed applet.  I understand this comprimised much of the
Java sandbox, but if you have a customer such as a large
bank or a .com company, they are going to be vehemently
opposed to the replacement of jar files in order to renew
certificates.  Asking customers to update code once a year
is unacceptable.

Sun supports using a self-signed applet through keytool.
However nice this is for private testing, this applet
cannot be deployed.  The step of importing through keytool
removes all elegance of a web-deployed applet.

Previous JVM versions allowed scanning of the Microsoft
X509 certificate cache, so a certificate could be
downloaded relatively painlessly.

Keytool is painful.  Enterprise customers will not buy into
keytool when they want the ease of a web interface
Rollout cycles absolutely forbid updating code at random
intervals
The limitation of only being able to renew certificates
before they expire often interacts with software
development cycles.

So, while signed applets work well when the signed applets
are deployed on a single web server, the scenarios break
down when these servers are installed behind closed doors,
and with very long periods where no updates are allowed.

VeriSign and THAWTE have admitted this problem exists... It
would be great if this could be addressed.

I'd hope for either
1) Ability to self-sign applets with some decent mechanism
of keystore import (such as a dialog within the plugin)
or 2) Discussion with VeriSign/THAWTE into issuing certs
with much longer life with digital ID's.
 



STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1.  N/A
2.
3.

REPRODUCIBILITY :
This bug can be reproduced always.
(Review ID: 160682) 
======================================================================