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.