Freshness proof

This article describes the concept of freshness proof, used in Nexus OCSP Responder.

In an OCSP request or response, the sending entity can include a proof that its certificate is not revoked. The proof implies that the responses, that are necessary to validate the signature chain, are included in the request/response.

If the receiving entity understands this proof and it was signed recently enough, there is no need to make another query to verify the status of the certificates. Consequently, the freshness proof functionality reduces the work for the receiving part and also for the root CA.

Example of flow:

1. Nexus OCSP Responder receives a request for revocation information of two certificates with the subject ID "cert ID #1" and "cert ID #2", respectively. 
2. The request is signed and a signature chain is included. 
3. The request also includes a freshness proof extension (OID 1.3.6.1.4.1.2390.3.5), containing two OCSP responses. These responses show the status of the requestor certificate and of the certificate for the subordinate CA.
4. Nexus OCSP Responder has to validate the signature chain of the incoming request, but can now use the responses in the freshness proof extension instead of going through a validation process.
5. When Nexus OCSP Responder sends its response to the requesting client, it includes the required revocation information and also a freshness proof extension. In this case the extension contains responses that show the status of the responder certificate and of the certificate for the subordinate CA.

It is possible that the CA certificate and/or the certificate of the subordinate CA are the same for the request and the response.