What's new in EJBCA 6 part 3: Internal Key Bindings

Welcome to the third part of the series about what is new in the upcoming EJBCA 6.
For the first part in the series, read Part 1: Crypto Tokens in GUI.

For the second part in the series, read Part 2: CMP aliases and GUI configuration.

In part 3 we take a look at a major new function in EJBCA 6 called Internal Key Bindings. This is a framework function, with two current applications, and can be used for more things in the future.
An Internal Key Binding can be used to make keys in a Crypto Token available for other uses than in a CA. It consists of a reference to a key pair available to the EJBCA instance, a non-CA certificate, an optional list of trusted certificates and properties for its purpose. It can be thought of as a simplified key store with purpose-specific properties.

So what can we do with internal key bindings?

The first thing is to introduce OCSP (RFC6960) Key Bindings. An OCSP Key Binding can be used to sign OCSP responses on behalf of a CA. It has a key in a Crypto Token and an OCSP signing certificate. Additionally a list of trusted certificates can be used to verify that OCSP requests are sent from a trusted source and additional properties can be used to specify how long an OCSP response should be valid etc.

What does this provide us that we could not do before?

Well for example:

• Cluster wide OCSP responder key configuration. Configure on one node, and all nodes sharing the same database will be configured.
• Full GUI support for configuration of OCSP responder keys and certificates. This is a function of the standard Admin GUI.
• Support for multiple Crypto Tokens in an OCSP responder. The old configuration file only supported one PKCS#11 slot.
• No need to load OCSP signing certificates into the HSM, signing certificate is read from the database.
• Full control of you OCSP signers.
• Mix delegated OCSP signers with direct CA signers, CAs and delegated OCSP responders can reside in the same instance. 

(See screenshots in the end)

What more can we do?

Authentication Key Bindings is a key binding used as identity in outgoing TLS connections, i.e. TLS client certificates. This can be used to authenticate an OCSP responder's web service calls when using web services to automatically renew certificates from a CA.

 On top of this it is possible to create new types of key bindings as we figure out new cool things. Anything that makes use of a key pair and a certificate gains the full maintenance options and HSM support of Internal Key Bindings.

Naturally there are a bunch of general maintenance options available for all Internal Key Bindings.

• Enable/Disable: Marks the Internal Key Binding as Active/Disabled. Only Active ones will be used and processed by healthcheck.
• Delete: Removes the Internal Key Binding, but will not remove the referenced key pair or certificates.
• New keys: Generates a new key pair in the referenced Crypto Token using the same key specification as the current key has and an alias derived from the current alias.
• CSR: Creates a Certificate Signing Request using the next key pair (or current key pair when no next key pair exists).
• Update: Searches the database for the latest issued matching certificate for the next key pair (or current key pair when no next key pair exists) by using SubjectKeyId.
• Renew: When the CA that issued the current certificate is active and resides in the same instance, this will create a new certificate using the same End Entity as the last one was issued with. If a next key pair exists, that key pair will be used.

Part 4 of "What's new in EJBCA 6" will be about Community vs Enterprise edition and how you, with EJBCA 6, will be able to actively participate in the development community.

Until then...check in with PrimeKey, or follow us on Twitter, for the latest news and events.

Pic 1: List of Key Bindings. There are tabs for different types of Key Bindings.

Pic 2: Editing an OCSP Key Binding.