Skip to main content

4. Details of the Protocol

4. Details of the Protocol​

The ASN.1 syntax imports terms defined in [RFC5280]. For signature calculation, the data to be signed is encoded using the ASN.1 distinguished encoding rules (DER) [X.690].

ASN.1 EXPLICIT tagging is used as a default unless specified otherwise.

The terms imported from elsewhere are Extensions, CertificateSerialNumber, SubjectPublicKeyInfo, Name, AlgorithmIdentifier, and CRLReason.

4.1. Request Syntax​

This section specifies the ASN.1 specification for a confirmation request. The actual formatting of the message could vary, depending on the transport mechanism used (HTTP, SMTP, LDAP, etc.).

4.1.1. ASN.1 Specification of the OCSP Request​

The ASN.1 structure corresponding to the OCSPRequest is:

OCSPRequest     ::=     SEQUENCE {
    tbsRequest                  TBSRequest,
    optionalSignature   [0]     EXPLICIT Signature OPTIONAL }

TBSRequest      ::=     SEQUENCE {
    version             [0]     EXPLICIT Version DEFAULT v1,
    requestorName       [1]     EXPLICIT GeneralName OPTIONAL,
    requestList                 SEQUENCE OF Request,
    requestExtensions   [2]     EXPLICIT Extensions OPTIONAL }

Signature       ::=     SEQUENCE {
    signatureAlgorithm      AlgorithmIdentifier,
    signature               BIT STRING,
    certs               [0] EXPLICIT SEQUENCE OF Certificate
OPTIONAL}

Version         ::=             INTEGER  {  v1(0) }

Request         ::=     SEQUENCE {
    reqCert                     CertID,
    singleRequestExtensions     [0] EXPLICIT Extensions OPTIONAL }

CertID          ::=     SEQUENCE {
    hashAlgorithm       AlgorithmIdentifier,
    issuerNameHash      OCTET STRING, -- Hash of issuer's DN
    issuerKeyHash       OCTET STRING, -- Hash of issuer's public key
    serialNumber        CertificateSerialNumber }

The fields in OCSPRequest have the following meanings:

  • tbsRequest is the optionally signed OCSP request.

  • optionalSignature contains the algorithm identifier and any associated algorithm parameters in signatureAlgorithm; the signature value in signature; and, optionally, certificates the server needs to verify the signed response (normally up to but not including the client's root certificate).

The contents of TBSRequest include the following fields:

  • version indicates the version of the protocol, which for this document is v1(0).

  • requestorName is OPTIONAL and indicates the name of the OCSP requestor.

  • requestList contains one or more single certificate status requests.

  • requestExtensions is OPTIONAL and includes extensions applicable to the requests found in reqCert. See Section 4.4.

The contents of Request include the following fields:

  • reqCert contains the identifier of a target certificate.

  • singleRequestExtensions is OPTIONAL and includes extensions applicable to this single certificate status request. See Section 4.4.

The contents of CertID include the following fields:

  • hashAlgorithm is the hash algorithm used to generate the issuerNameHash and issuerKeyHash values.

  • issuerNameHash is the hash of the issuer's distinguished name (DN). The hash shall be calculated over the DER encoding of the issuer's name field in the certificate being checked.

  • issuerKeyHash is the hash of the issuer's public key. The hash shall be calculated over the value (excluding tag and length) of the subject public key field in the issuer's certificate.

  • serialNumber is the serial number of the certificate for which status is being requested.

4.1.2. Notes on OCSP Requests​

The primary reason to use the hash of the CA's public key in addition to the hash of the CA's name to identify the issuer is that it is possible that two CAs may choose to use the same Name (uniqueness in the Name is a recommendation that cannot be enforced). Two CAs will never, however, have the same public key unless the CAs either explicitly decided to share their private key or the key of one of the CAs was compromised.

Support for any specific extension is OPTIONAL. The critical flag SHOULD NOT be set for any of them. Section 4.4 suggests several useful extensions. Additional extensions MAY be defined in additional RFCs. Unrecognized extensions MUST be ignored (unless they have the critical flag set and are not understood).

The requestor MAY choose to sign the OCSP request. In that case, the signature is computed over the tbsRequest structure. If the request is signed, the requestor SHALL specify its name in the requestorName field. Also, for signed requests, the requestor MAY include certificates that help the OCSP responder verify the requestor's signature in the certs field of Signature.

4.2. Response Syntax​

This section specifies the ASN.1 specification for a confirmation response. The actual formatting of the message could vary, depending on the transport mechanism used (HTTP, SMTP, LDAP, etc.).

4.2.1. ASN.1 Specification of the OCSP Response​

An OCSP response at a minimum consists of a responseStatus field indicating the processing status of the prior request. If the value of responseStatus is one of the error conditions, the responseBytes field is not set.

OCSPResponse ::= SEQUENCE {
   responseStatus         OCSPResponseStatus,
   responseBytes          [0] EXPLICIT ResponseBytes OPTIONAL }

OCSPResponseStatus ::= ENUMERATED {
    successful            (0),  -- Response has valid confirmations
    malformedRequest      (1),  -- Illegal confirmation request
    internalError         (2),  -- Internal error in issuer
    tryLater              (3),  -- Try again later
                                -- (4) is not used
    sigRequired           (5),  -- Must sign the request
    unauthorized          (6)   -- Request unauthorized
}

The value for responseBytes consists of an OBJECT IDENTIFIER and a response syntax identified by that OID encoded as an OCTET STRING.

ResponseBytes ::=       SEQUENCE {
    responseType   OBJECT IDENTIFIER,
    response       OCTET STRING }

For a basic OCSP responder, responseType will be id-pkix-ocsp-basic.

id-pkix-ocsp           OBJECT IDENTIFIER ::= { id-ad-ocsp }
id-pkix-ocsp-basic     OBJECT IDENTIFIER ::= { id-pkix-ocsp 1 }

OCSP responders SHALL be capable of producing responses of the id-pkix-ocsp-basic response type. Correspondingly, OCSP clients SHALL be capable of receiving and processing responses of the id-pkix-ocsp-basic response type.

The value for response SHALL be the DER encoding of BasicOCSPResponse.

BasicOCSPResponse       ::= SEQUENCE {
   tbsResponseData      ResponseData,
   signatureAlgorithm   AlgorithmIdentifier,
   signature            BIT STRING,
   certs            [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL }

The value for signature SHALL be computed on the hash of the DER encoding of ResponseData. The responder MAY include certificates in the certs field of BasicOCSPResponse that help the OCSP client verify the responder's signature. If no certificates are included, then certs SHOULD be absent.

ResponseData ::= SEQUENCE {
   version              [0] EXPLICIT Version DEFAULT v1,
   responderID              ResponderID,
   producedAt               GeneralizedTime,
   responses                SEQUENCE OF SingleResponse,
   responseExtensions   [1] EXPLICIT Extensions OPTIONAL }

ResponderID ::= CHOICE {
   byName               [1] Name,
   byKey                [2] KeyHash }

KeyHash ::= OCTET STRING -- SHA-1 hash of responder's public key
(excluding the tag and length fields)

SingleResponse ::= SEQUENCE {
   certID                       CertID,
   certStatus                   CertStatus,
   thisUpdate                   GeneralizedTime,
   nextUpdate         [0]       EXPLICIT GeneralizedTime OPTIONAL,
   singleExtensions   [1]       EXPLICIT Extensions OPTIONAL }

CertStatus ::= CHOICE {
    good        [0]     IMPLICIT NULL,
    revoked     [1]     IMPLICIT RevokedInfo,
    unknown     [2]     IMPLICIT UnknownInfo }

RevokedInfo ::= SEQUENCE {
    revocationTime              GeneralizedTime,
    revocationReason    [0]     EXPLICIT CRLReason OPTIONAL }

UnknownInfo ::= NULL

4.2.2. Notes on OCSP Responses​

4.2.2.1. Time​

Responses can contain four times -- thisUpdate, nextUpdate, producedAt, and revocationTime. The semantics of these fields are defined in Section 2.4. The format for GeneralizedTime is as specified in Section 4.1.2.5.2 of [RFC5280].

The thisUpdate and nextUpdate fields define a recommended validity interval. This interval corresponds to the {thisUpdate, nextUpdate} interval in CRLs. Responses whose nextUpdate value is earlier than the local system time value SHOULD be considered unreliable. Responses whose thisUpdate time is later than the local system time SHOULD be considered unreliable.

If nextUpdate is not set, the responder is indicating that newer revocation information is available all the time.

4.2.2.2. Authorized Responders​

The key that signs a certificate's status information need not be the same key that signed the certificate. It is necessary, however, to ensure that the entity signing this information is authorized to do so. Therefore, a certificate's issuer MUST do one of the following:

  • sign the OCSP responses itself, or

  • explicitly designate this authority to another entity

OCSP signing delegation SHALL be designated by the inclusion of id-kp-OCSPSigning in an extended key usage certificate extension included in the OCSP response signer's certificate. This certificate MUST be issued directly by the CA that is identified in the request.

The CA SHOULD use the same issuing key to issue a delegation certificate as that used to sign the certificate being checked for revocation. Systems relying on OCSP responses MUST recognize a delegation certificate as being issued by the CA that issued the certificate in question only if the delegation certificate and the certificate being checked for revocation were signed by the same key.

Note: For backwards compatibility with RFC 2560 [RFC2560], it is not prohibited to issue a certificate for an Authorized Responder using a different issuing key than the key used to issue the certificate being checked for revocation. However, such a practice is strongly discouraged, since clients are not required to recognize a responder with such a certificate as an Authorized Responder.

id-kp-OCSPSigning OBJECT IDENTIFIER ::= {id-kp 9}

Systems or applications that rely on OCSP responses MUST be capable of detecting and enforcing the use of the id-kp-OCSPSigning value as described above. They MAY provide a means of locally configuring one or more OCSP signing authorities and specifying the set of CAs for which each signing authority is trusted. They MUST reject the response if the certificate required to validate the signature on the response does not meet at least one of the following criteria:

  1. Matches a local configuration of OCSP signing authority for the certificate in question, or

  2. Is the certificate of the CA that issued the certificate in question, or

  3. Includes a value of id-kp-OCSPSigning in an extended key usage extension and is issued by the CA that issued the certificate in question as stated above.

Additional acceptance or rejection criteria may apply to either the response itself or to the certificate used to validate the signature on the response.

4.2.2.2.1. Revocation Checking of an Authorized Responder​

Since an authorized OCSP responder provides status information for one or more CAs, OCSP clients need to know how to check that an Authorized Responder's certificate has not been revoked. CAs may choose to deal with this problem in one of three ways:

  • A CA may specify that an OCSP client can trust a responder for the lifetime of the responder's certificate. The CA does so by including the extension id-pkix-ocsp-nocheck. This SHOULD be a non-critical extension. The value of the extension SHALL be NULL. CAs issuing such a certificate should realize that a compromise of the responder's key is as serious as the compromise of a CA key used to sign CRLs, at least for the validity period of this certificate. CAs may choose to issue this type of certificate with a very short lifetime and renew it frequently.
id-pkix-ocsp-nocheck OBJECT IDENTIFIER ::= { id-pkix-ocsp 5 }

  • A CA may specify how the responder's certificate is to be checked for revocation. This can be done by using CRL Distribution Points if the check should be done using CRLs, or by using Authority Information Access if the check should be done in some other way. Details for specifying either of these two mechanisms are available in [RFC5280].

  • A CA may choose not to specify any method of revocation checking for the responder's certificate, in which case it would be up to the OCSP client's local security policy to decide whether that certificate should be checked for revocation or not.

4.2.2.3. Basic Response​

The basic response type contains:

  • the version of the response syntax, which MUST be v1 (value is 0) for this version of the basic response syntax;

  • either the name of the responder or a hash of the responder's public key as the ResponderID;

  • the time at which the response was generated;

  • responses for each of the certificates in a request;

  • optional extensions;

  • a signature computed across a hash of the response; and

  • the signature algorithm OID.

The purpose of the ResponderID information is to allow clients to find the certificate used to sign a signed OCSP response. Therefore, the information MUST correspond to the certificate that was used to sign the response.

The responder MAY include certificates in the certs field of BasicOCSPResponse that help the OCSP client verify the responder's signature.

The response for each of the certificates in a request consists of:

  • an identifier of the certificate for which revocation status information is being provided (i.e., the target certificate);

  • the revocation status of the certificate (good, revoked, or unknown); if revoked, it indicates the time at which the certificate was revoked and, optionally, the reason why it was revoked;

  • the validity interval of the response; and

  • optional extensions.

The response MUST include a SingleResponse for each certificate in the request. The response SHOULD NOT include any additional SingleResponse elements, but, for example, OCSP responders that pre-generate status responses might include additional SingleResponse elements if necessary to improve response pre-generation performance or cache efficiency (according to [RFC5019], Section 2.2.1).

4.3. Mandatory and Optional Cryptographic Algorithms​

Clients that request OCSP services SHALL be capable of processing responses signed using RSA with SHA-256 (identified by the sha256WithRSAEncryption OID specified in [RFC4055]). Clients SHOULD also be capable of processing responses signed using RSA with SHA-1 (identified by the sha1WithRSAEncryption OID specified in [RFC3279]) and the Digital Signature Algorithm (DSA) with SHA-1 (identified by the id-dsa-with-sha1 OID specified in [RFC3279]). Clients MAY support other algorithms.

Last updated on