Introduction

The number of design dimensions for OpenSign applet was extended for the bootable edition so it now supports the following:

JVMs

Currently the following JVMs are supported:

  • MS JVM
  • SUN JVM
The applet is determining which JVM it is running on and using dependent libraries depending on it.

Java Security

The applet needs to execute restricted code like reading certificates and files on the client computer. The security archictecture for allowing this to happen in a MS JVM (1.1.4) and SUN JVM (1.4+) has changed.

For MS JVM in a browser, the applet classloader doesn't allow the applet to install a securitymanager and the way to execute restricted code is to have the code signed and call PolicyEngine.assertPermission() in the same stack frame as the dangerous code. For SUN JVM, you can install a security manager but it also works with calling AccessController.doPrivileged() in signed code.

In order to make it work in all (both) JVM's, all calls to restricted code is performed by an object implementing RestrictedAction which lives in the signed part of the code (OpenSign-bootstrapped.jar/cab). The rest of the code is zipped in plugins which can be loaded when they are needed. The plugins then calls restricted code through its RestrictedAction object.

The plugins are loaded if a check of the local cache (on .oces/opensign/plugins) reveals that they are not present in the correct version.

Applets

The BootApplet is responsible for downloading and checking the code for the real applet and otherwise tries to remain invisible and relays all information between the HTML-page, the applet, the browser and the user in a transparent way.

The real applet doesn't need to have anything to do with OpenSign in order to be used with BootApplet.

You can configure which applet is the real applet by setting the ZIP_FILE_ALIAS. Currently the following aliases are supported:

  • OpenSign for signing text (Sign)
  • OpenLogon for logon (Logon)
  • OpenService for a GUI-less applet (PassApplet)

If the real Applet is PlugAware plugins can be added to it with the addPlugin() method. Sign and Logon supports plugins of type KeyStoreHandler and CryptoSupport.

Keystores

With the bootable edition, the number of supported keystores was increased from 2 to 3 and it was then decided to set it to "N" instead. Currently the following keystores are supported:

  • PKCS12
  • CAPI
  • CD card

It is determined which keystores to support by configuring the applet parameter EXTRA_ZIP_FILE_NAMES. The applet checks on runtime if the keystore is supported on the JVM/OS and loads certificates from that store if so. For example is CAPI only supported on Windows so it is only loaded on this OS.

In order to add a new keystore, the following must be done:

  • A keystore must extend the class KeyStoreHandler.
  • Each certificate must implement the interfaceAbstractCertificateHandler
  • The keystore is packed in a jar-file and added to OpenSigndownloads as a DownloadItem.

Crypto library

BootApplet supports loading a plugin depending on the JVM being run.

If it is MS JVM, the plugin named MS_SUPPORT is loaded.

If it is SUN JVM, the plugin named SUN_SUPPORT is loaded.

For OpenSign, these libraries extends the crypto libraries in the JVMs and must implement CryptoSupport.

  • For MS JVM it is currently the closed source iaik
  • For SUN JVM is is named jsse

Input/Output

Some support of various ways to read input and produce XMLDSIG has been added to OpenSign. A ParamReader can be selected which gives access to a SignatureGenerator.

Currently it is supported by Logon in the form of a parameter VIRK_LOGON

and by Sign by parsing the signtext parameter for xml content and using VirkSignatureGenerator in that case.

The following aspects can be changed by selecting another ParamReader

  • The format of the input parameters
  • The format of the XMLDSIG output
  • The format of locale-specific items (not supported yet)

Locales

Locale is set with the parameter locale and defaults to da,DK. New locales can be supported by implementing a class Resource_lang_Country and currently the following locales are supported:

  • en,US
  • da,DK
  • ca,ES

Some implementors may want to have more detailed control over the labels in the GUI. In the future, some support for controlling this through applet parameters may be added.