13 Hardcore EJBCA PKI options explained

This blog post is based on my 'Hardcore PKI' presentation at PrimeKey Tech Days 2015. The EJBCA functions described can help you integrate PKI more efficiently for specific use cases.

What is hardcore PKI?

Technologies such as ASN.1 and X.509, RSA and ECC Standards and APIs are extremely complex for most users and developers, and the important process of fitting them all together in standards (to enable interoperable systems) is very hard. However, implementors of PKI systems don't have to care about these hardcore technologies due to a few helpful tools:

• ASN.1 parsing is done using the library BouncyCastle. 
• Digital signatures with RSA and ECC is also done either using BouncyCastle in software, or it is done in Hardware Security Modules.
• Standardization is done by organizations such as IEFT and Oasis.

When people think about PKI they often think about hardcore technologies, but because of these handy tools, the technologies themselves are not what is hardcore about PKI.

The Devil is in the Detail

Hardcore PKI, in my opinion, is that everybody needs and uses PKI, but always in slightly different ways. This demands from the PKI to have the ability to support a lot of different architectures (which EJBCA does) and from you to be able to configure and fine tune your PKI according to your precise needs. The devil is in the details!

The many possibilities of configuring several details is really the hardcore part in PKI.

Thirteen EJBCA options explained

Here are thirteen examples of hardcore details that can truly make your PKI better integrated. But unless you are looking for one or more of these specific features,  these options may appear somewhat incomprehensible.

One reason for EJBCA to provide all these functions is to support policy enforcement all the way from Complete Enforcement by the CA, to All Enforcement in the RA (where the CA trusts the RA blindly).

On to the details! Most of the options are also described in the EJBCA User Guide.

Permissions

EJBCA Certificate Profile options: override and certificate storage

• Allow validity override – Normally validity is determined by the certificate profiles, but with this option the validity period can be taken from the request sent by the client/RA.
• Allow extension override – Normally certificate extensions are determined by the certificate profiles, but with this option the extensions can be taken from the request sent by the client/RA.
• Allow DN override – Normally the DN is pre-registered and determined by the end entity record, but with this option the DN can be taken from the request sent by the client/RA.
• Use Certificate storage – An interesting option where you can choose to not store issued certificates in the CA database. This fits specific use cases where revocation never needs to happen and you want to issue large amounts of certificates without the burden of administrating a growing CA database. A kind of fire and forget CA.
  

Other data

EJBCA Certificate Profile options: CN postfix and single active certificate

• Use CN postfix – tells the CA to add some text after the CN in the issued certificate. Can be used to get user friendly names (like 'Tomas – Encryption' and 'Tomas – Signing') in browser certificate dialogues.
• Use DN and altName subset – use this if you want to register more information about end entities, than is visible in the issued certificate.
• Approvals – enforces dual control (or four eyes principle) for certain functions such as revocation and key recovery.
• Single Active Certificate Constraint – automatically revokes an end entity's old certificate when a new certificate is retrieved. This ensures that a user or device can only use one certificate at a certain point in time.

Directives

EJBCA Certificate Profile options: enforce public key and DN

• Enforce unique public keys – makes two end entities unable to use the same public key.
• Enforce unique DN – makes two end entities unable to share the same subject DN.
• Enforce unique Subject DN SerialNumber - makes two end entities unable to share the same SerialNumber component in the Subject DN. The SerialNumber in the DN is typically used for device serial numbers, thus ensuring that one device is only registered as a single end entity.
• Use User Storage – when disabled, end entities are not stored in the database when issuing certificates through an RA capable protocol. Saves space in the database, but removes some functionality.
• Use Certificate Storage – when disabled, certificates are not stored in the database when issued. This option enables issuing of billions of certificates without using any storage space, but on the other hand disables several of the commonly required PKI functions such as revocation.

The Key Take Aways

All of the obscure functions described above are used in real life, for various use cases. Some very domain specific, some more generic. The key take away, is that these functions provide short-cuts for use cases where you thought you would have to do work-arounds, or be limited by the capabilities of a specific product. With the functions described (and several others) you can integrate PKI in your use case in the most efficient way, only having your imagination setting the boundaries.

EJBCA Enterprise

In EJBCA Enterprise we strive for maximum flexibility, only having a single platform to manage all needs of PKI. This means EJBCA has to be available for all platforms, and be ready to implement many protocols and multiple APIs, while enabling you to use your PKI from many locations. In order to do this we need to support many different PKI architectures (as was explained here).

More information

Basic information on EJBCA Enterprise PKI and PKI Appliance developed by PrimeKey.

EJBCA is a registered trademark of PrimeKey Solutions AB in the EU, the United States, Japan and certain other countries.