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.