What's new in EJBCA 6. Part 1: Crypto Tokens in GUI

This is the first post in a series about what is new in the upcoming EJBCA 6. EJBCA 6 will be released, in both a Community and Enterprise Edition (more about that in a later post) during the autumn.
EJBCA 6 is a major evolution of EJBCA with another technology upgrade (Java 7, JBoss 7), many new cool features and lots of improvements. So far more than 200 issues has been fixed, reviewed and closed and a few more remains.
Why do we go up from EJBCA 4/5 to EJBCA 6? This is because there are new features that changes the way administrators interact with EJBCA. So administrative work-flows change a bit and a new major version number indicates that administrators might need updated training, and integrations should be thoroughly tested.

Enough about that, and on to todays topic. Crypto Tokens and Crypto Tokens in Admin GUI.

In EJBCA 6 we introduce the concept of separated, generic crypto tokens. Previously a CAs keys have been tighly tied to the CA (as a configuration object). In EJBCA 6 there is a new concept of a crypto token than can be shared among multiple CAs or other services such as OCSP. A crypto token is simply a keystore and can be a software keystore in the database or a hardware keystore such as a PKCS#11 slot on a HSM.
Being separated from CAs you can create, edit and delete unlimited number of crypto tokens individually, not re-configuring any CAs or services. For a crypto token you can create and configure the token (such as PKCS#11 driver, slot etc), generate and delete keys, test keys and create CSRs for individual keys. When you create CAs or OCSP services you connect them to an existing crypto token and select which keys on the token should be used for which purposes, all using simple lists that presents you with what is on the token. No need to use separate tools to to manage keys on the token.

So what benefits does this give you?

1. Clear and easy to understand management of cryptographic keys. Click and go, no strange HSM commands, no weird hard token properties, easy overview of your HSMs and keys.
2. Full Admin GUI support for key management, including HSM management with easy drop down selections of your type of HSM. No more editing properties! Generate and manage your keys from the GUI, including full audit logging.
3. There are also usability short cuts, such as automatic crypto token creation when creating a new soft token CA, to make it easy to get going. But it is really easy to understand the important aspect of key management in a high security PKI environment.
4. Easy to see and share a single HSM configuration for multiple CAs. No need to configure the same HSM slot multiple times.
5. Easy renewal and creation of link certificates for CAs. Simple generate new keys on the crypto token (during a key ceremony?) and renew the CA using by selecting a key in a drop down list and renewing the CA.
6. Since crypto tokens are not tied to CAs you can configure them for OCSP as well. This gives GUI support for standalone OCSP responders through the use of OCSP Key Bindings.
7. Re-use crypto tokens easily for future services.
8. and more...

Another thing with the new crypto tokens is that you can use slot number, slot index or slot label to identify a slot. This is good news for users of some HSMs that either have random slot numbers or that may have different slot numbers on different HSMs in a High Availability (HA) environment.

Needles to say, we think this new feature is awesome. Since I don't know much about other products I can't say it is unique, but it's a leap forward in usability for us.

Part 2 of "What's new in EJBCA 6" will be about new improved CMP configuration and CMP aliases.

Until then...