EJBCA and the updated OCSP RFC 6960

There has recently been posted an update to the old trusted OCSP RFC (rfc2560). The updates in the new RFC6960 are quite few (a good grade for the old RFC, which is exemplary simple yet effective) and clarifies a few points that were previously seen as ambiguous, and could lead to different implementations. It also introduces a few new OCSP extensions.

So how does EJBCA stand on the new RFC? Below I will go through the most important changes, that are relevant for EJBCA implementation.
Changes not mentioned here are either optional and never used/requested in EJBCA, or are already implemented fully by EJBCA OCSP.

o  DONE: Section 2.2 extends the use of the "revoked" response to allow
      this response status for certificates that have never been issued.

This allows responders (MAY) to return "revoked" status for certificates that are unknown to the OCSP responder.
EJBCA was always designed to include all issued certificates, and to provide "unknown" response for certificates that are really unknown to the responder. So for along time EJBCA was ahead of the pack, prohibiting "ok" responses for certificates the responder did no know about.
In practice an "unknown" response will be treated the same as "revoked" in most cases, i.e. the transaction denied. There was a discussion about the possibility of clients falling back to CRL processing in the case of "unknown", hence the new requirement to respond "revoked" also for unknown certificates.

ECA-3132 has been created to allow responders to be configured to also return "revoked" for unknown certificates, not only "unknown".

o Section 4.4.7 specifies a new extension that may be included in a
      request message to specify signature algorithms the client would
      prefer the server use to sign the response as specified in [RFC6277].

This option is probably far away from being used in the wild. It can however be interesting for EJBCA to support it in the future.

ECA-3133 has been created to eventually cater for this extension.

o  DONE: Section 4.4.8 specifies a new extension that indicates that the
      responder supports the extended use of the "revoked" response for
      non-issued certificates defined in Section 2.2.

This extension would also be supported as of ECA-3132 above.

This was it! The noteworthy thing is returning of "revoked" status for certificates that are unknown to the responder. It's a small change, brought in by the latest years CA compromises and the work of
browsers and CAs to increase security, and improve interoperability amongs vendors. OCSP has proven to be a remarkably simple, robust, interoperable and widely used protocol, as opposed to many other protocols.
May it live long.

Visit PrimeKey for more information about support subscriptions for EJBCA OCSP Responder.

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...

EJBCA 4.0.16 released

The PrimeKey EJBCA team is happy to announce that EJBCA 4.0.16 has been
released! This is a maintenance release of the EJBCA Community version –
3 issues have been resolved. The most noteworthy changes can be seen below.
This maintenance release contains 1 new feature and 2 bugfixes.

• It is now possible to store the Base64 certificate data in a separate table. This can improve database scalability for massive scale PKIs with hundreds of millions of certificate.

• Fixed possible database rollback when CRL publishing failed.

• Fixed a possible exception viewing old log in the Admin GUI.

Please visit http://www.ejbca.org/ for more information.

SignServer 3.4.1 released

11 June 2013 — Stockholm, Sweden

The PrimeKey SignServer team is happy to announce that SignServer 3.4.1 has been released! This is a maintenance release – in total 19 features, options, bugs and stabilizations have been fixed or added. The most noteworthy changes can be seen below.

SignServer *3.4.1* release notes

• New features and improvements

  • Support for specifying the signature algorithm in CMS signer.
  • Added support for IPv6 and multiple proxies in ListBasedAddressAuthorizer.
  • Added an option to set the correct TSA name from the subject DN automatically for the time stamp signer.
  • Support for the signerCertificate attribute in the MS Authenticode time stamp signer.
  • Support for generating CSR with ECDSA explicit parameters in the admin GUI and the RenewalWorker.
  • Log worker name in the worker log.
  • Easy import of issuer and serial number from certificate in admin GUI, when adding administrator rules.
  • All workers report themselves as offline when misconfigured.
  • Added health check rate limiter.
  • Added database setup scripts for PostgreSQL.

• Bug fixes

  • ContentInfo contained a double encoded octet string in the MS Authenticode time stamp signer.
  • Unauthorized health check queries incorrectly logged.

Development continues beyond this version and all requests from the community are scheduled for SignServer 3.4.2 or later releases.
More information is available at the project web site and the complete changelog can be viewed in the issue tracker.

EJBCA 4.0.15 released

10 May 2013 — Stockholm, Sweden

The PrimeKey EJBCA team is happy to announce that EJBCA 4.0.15 has been released! This is a maintenance release — 5 issues have been resolved. The most noteworthy changes can be seen below.

EJBCA PKI *4.0.15* release notes

A maintenance release containing 2 new features and 3 improvements.

• New Features

  • It is now possible to publish certificate serial number in LDAP using a custom LDAP schema.
  • When creating link certificates, a certificate profile can now be used.

• Improvements

  • Two new fields (C and UID) added to end entity email notification, by David Carella.
  • Debug log message when healthcheck fails, makes debugging easier.

• Bug fixes

  • No bugs found!

Development continues beyond this version and all requests from the community are scheduled for EJBCA 4.0.16 or later releases.
More information is available at the project web site and the complete changelog can be viewed in the issue tracker.

SignServer 3.4.0 released

3 April 2013 — Stockholm, Sweden

The PrimeKey SignServer team is happy to announce that SignServer 3.4.0 has been released! This is a major release – in total 27 features, options, bugs and stabilizations have been fixed or added. The most noteworthy changes can be seen below.

SignServer *3.4.0* release notes

• Major changes

  • Secure logging to database using CESeCore.
  • Support for querying audit log from CLI, GUI and web services.
  • Configurable which Status Repository updates to log.
  • Access group for auditors.
  • Database CLI for verifying audit log.
  • Support for PostgreSQL. 

• Bug fixes

  • Fixed a couple of NPE bugs.
  • Fixed logging in over webservices using a JKS keystore in the Admin GUI.
  • Fixed some randomly failing unit tests.
  • Other minor bugfixes.

Development continues beyond this version and all requests from the community are scheduled for SignServer 3.4.1 or later releases.
More information is available at the project web site and the complete changelog can be viewed in the issue tracker.

EJBCA 5.0.9 released

21 March 2013 — Stockholm, Sweden

Primekey proudly presents the 5.0.9 maintenance release of EJBCA.
Quite some effort has been put into stabilizing the 5.0.x release for production, upgrade and audit use, including bug fixes and improvements of usability for issues discovered during production deployments.

EJBCA PKI *5.0.9* release notes

A maintenance release containing improvements and a few bug fixes. The following are a selection of the most noteworthy:

• New features

  • CMP vendor certificate authorization.
  • New publisher cache for better performance.
  • New ClientToolbox command to batch generate keys.
  • EJBCA now compiles and runs on JDK7.

• Bug fixes

  • Fixed an upgrade problem from 4.0.
  • Fixed revocation of CAs not performing as expected in all circumstances.
  • Fixed renewal not always persisting the keys.
  • Other minor bugfixes and improvements.

Development continues beyond this version and all requests from the community are scheduled for EJBCA 5.0.10 or later releases.
More information is available at the project web site and the complete changelog can be viewed in the issue tracker.