...
An OCSP client issues a status request to an OCSP responder and suspends acceptance of the certificate in question until the responder provides a response.
...
Data in an OCSP request
The OCSP request specifies the data that needs to be exchanged between an application checking the status of a certificate and the server providing that status.
An OCSP request contains the following data:
Protocol version
Service request
Target certificate identifier
Optional extensions which may be processed by the OCSP responder
...
Content of a response message
Definitive response message
A definitive response message is composed of:
Version of the response syntax
Name of the OCSP responder
Responses for each of the certificates in a request
Optional extensions
Signature
Response message for each certificate
The response for each of the certificates in a request consists of:
Target certificate identifier, which consists of the following:
Hash of the issuer (CA) distinguished name
Hash of the issuer (CA) public key
Serial number of the target certificate
Also: the OCSP responder must have access to the issuer (CA) certificate to get the public key.
Certificate status value
Response validity interval
Optional extensions
Certificate status values
The response indicators for use in the certificate status value are:
good | The "good" state indicates a positive response to the status inquiry. At a minimum, this positive response indicates that the certificate is not revoked, but does not necessarily mean that the certificate was ever issued or that the time at which the response was produced is within the certificate's validity interval. Response extensions may be used to convey additional information on assertions made by the responder regarding the status of the certificate, such as positive statement about issuance, validity, etc. |
---|---|
revoked | The "revoked" state indicates that the certificate has been revoked (either permanently or temporarily, that is, on hold). |
unknown | The "unknown" state indicates that the responder has no possibility to answer the inquiry. The reason for this might be that the issuer is unknown, that no revocation information is available, for example, the CRL of the issuer, etc. |
Time included in responses
Responses can contain three times:
thisUpdate | The time at which the status being indicated is known to be correct. |
---|---|
nextUpdate | The time at or before which newer information will be available about the status of the certificate. If nextUpdate is not set, the responder is indicating that newer revocation information may be available all the time. |
producedAt | The time at which the responder signed this response. |
OCSP responders may pre-produce signed responses specifying the status of certificates at a specified time. The time at which the status was known to be correct shall be reflected in the thisUpdate field of the response. The time at or before which newer information will be available is reflected in the nextUpdate field, while the time at which the response was produced will appear in the producedAt field of the response.
Sign definitive response message
All definitive response messages shall be digitally signed. The key used to sign the response must belong to one of the following:
The CA who issued the certificate in question
A Trusted Responder whose public key is trusted by the requester
A CA designated responder (authorized responder) who holds a specially marked certificate issued directly by the CA, indicating that the responder may issue OCSP responses for that CA
...
Non-issued certificates
Included in the specification RFC 6960 X.509 Internet Public Key Infrastructure Online Certificate Status Protocol – OCSP, there is a description of non-issued certificates, where the responder may reply that the certificate is revoked with the date 1970-01-01 if the certificates in the request have not been issued. This is implemented in Nexus OCSP Responder by help of Certificate Issuance Lists. See more in Certificate Issuance List - CIL.