A key part to achieving the vision of the Eclipse RCP as a secure client is a well defined, robust and extensible architecture for storing encryption keys, digital certificates and other credentials. It is proposed that Eclipse RCP adopt the Java 2 KeyStoreSPI, KeyStore, and as the basis for its keystore implementation. Adopting this interface will make it possible for the Eclipse RCP to more easily integrate with other Java security technologies such as code signing (and associated CodeSource-based authorization), and Java Secure Sockets Extension (JSSE).

Three very important and integral parts of the overall security architecture are the Java Cryptography Architecture (JCA), the Java Cryptography Extension (JCE), and the Java Secure Socket Extension (JSSE). Together the JCA and JCE provide a platform independent cryptography API. "The JSSE is a set of Java packages and APIs that enable the use of SSL from within Java programs. JSSE provides a framework and an implementation for the SSL and TLS protocols and includes functionality for data encryption, server authentication, message integrity, and optional client authentication."¹

SSL and TLS use symmetric cryptography for data integrity and public-key cryptography for authentication and identification.

In addition to SSL and TLS, the Java SecurityManager and AccessContoller also rely on public-key cryptography. The SecurityManager and AccessController collaborate to enforce access-control based on digital signatures that have been applied to code, and the URL location from which the code originated. JAAS makes it possible to refine access-control to take into account the user who runs the code as well.

To effectively use public-key cryptography some of a public key infrastructure (PKI) is required. Java 2 provides a set of security tools (keytool, jarsigner) for creating and managing keys and certificates and signing JAR files. These utilities use a keystore as a minimal PKI for storing encryption keys (public and private) and certificates. A keystore is a collection of keys. Private keys in a keystore have a certificate chain associated with them, which authenticates the corresponding public key. A keystore also contains certificates from trusted entities. The latter is sometimes referred to as a truststore. In addition, Java 1.4.2 introduces the CertStore, for storing and accessing a potentially vast repository of untrusted certificates and CRLs (Certificate Revocation Lists). Keystore and Truststore are accessed by classes that implement the Java 2 KeyManager and TrustManager interfaces.

A credentialstore is a collection of user or application specific credentials, like username/password combinations for login access to a variety of systems. Conceptually this is similar to a password vault or password manager found in many popular applications and browsers.

Keystores, truststores and credentialstores can be the same file. However it may be more secure for protecting and easier to manage keys and credentials if they are separate. For example, for a high level of security a users private keys could be stored on a smartcard, but the truststore may be stored in a file on disk.

The Java 2 SDK provides a reference implementation (JKS) of Keystore. Other JRE or JCE vendors may include additional keystore implementations as well. For example the IBM JRE/JDK provides a "JCEKS" keystore which uses encryption to protect the keystore. In comparison the default "JKS" uses a hash value to protect the keystore from alteration.

• For Eclipse, and for RCP in particular, how should the KeyStore be implemented and integrated into Eclipse?
• Should keys and other credentials be stored together or separately?
• How should the keys and credentials be managed locally and centrally?