Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-4731841

Verisign Model Inconsistant w/ Enterprise Deployment Scenarios

XMLWordPrintable

    • Icon: Enhancement Enhancement
    • Resolution: Duplicate
    • Icon: P4 P4
    • None
    • 1.4.0
    • deploy
    • x86
    • windows_2000



      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)
      ======================================================================

            dgu Dennis Gu (Inactive)
            gmanwanisunw Girish Manwani (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

              Created:
              Updated:
              Resolved:
              Imported:
              Indexed: