X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP
obsoletes
- rfc-2560 — X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP
- rfc-6277 — Online Certificate Status Protocol Algorithm Agility
updated by
- rfc-8954 — Online Certificate Status Protocol (OCSP) Nonce Extension
- rfc-9654 — Online Certificate Status Protocol (OCSP) Nonce Extension
updates
- rfc-5912 — New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX)
Extracted elements (31)
CertID includes both issuerNameHash and issuerKeyHash because two CAs may coincidentally use the same distinguished name (DN uniqueness is a recommendation, not enforceable), whereas two CAs will never share the same public key unless deliberately or through compromise.
The Preferred Signature Algorithms extension was added because RFC 2560 provided no mechanism for clients to indicate algorithm preferences, creating a risk that a responder choosing a non-mandatory algorithm would produce a response the client cannot verify. The extension also enables responders to use a lighter-weight algorithm than the one used to sign certificates.
The 'revoked' response (rather than 'unknown') is extended to non-issued certificates so the client rejects the certificate outright rather than falling back to another status source such as a CRL. The 'unknown' response would invite retries, while 'revoked' definitively blocks use of a certificate that was never legitimately issued.
HTTP GET may be used for OCSP requests that after base-64 and URL encoding are less than 255 bytes (to enable HTTP caching); larger requests SHOULD use POST with Content-Type application/ocsp-request. Responses use Content-Type application/ocsp-response with the binary DER-encoded OCSPResponse as the body.
A client MUST support each of its specified preferred signature algorithms and MUST list them in order from most preferred to least preferred. A responder SHOULD apply the lowest-precedence selection that yields a supported, secure algorithm: (1) client preferred, (2) CRL signing algorithm, (3) request signing algorithm, (4) out-of-band default, (5) mandatory/recommended algorithm.
All definitive OCSP response messages SHALL be digitally signed. The signing key MUST belong to the CA that issued the certificate, a Trusted Responder whose public key is trusted by the requestor, or a CA Designated Responder holding a specially marked certificate issued directly by the CA.
Before accepting a signed OCSP response, clients SHALL confirm: the certificate in the response matches the request, the signature is valid, the signer identity matches the intended recipient, the signer is currently authorized, thisUpdate is sufficiently recent, and (when present) nextUpdate is greater than current time.
CAs SHALL provide the authority information access extension in certificates that can be checked using OCSP, and MUST include a URI accessLocation with OID id-ad-ocsp as the accessMethod for the OCSP service.
Clients that request OCSP services SHALL be capable of processing responses signed with RSA with SHA-256 (sha256WithRSAEncryption). Clients SHOULD also support RSA with SHA-1 and DSA with SHA-1, and MAY support other algorithms.
OCSP responders SHALL be capable of producing id-pkix-ocsp-basic responses, and OCSP clients SHALL be capable of receiving and processing id-pkix-ocsp-basic responses. The response value SHALL be the DER encoding of BasicOCSPResponse.
OCSP signing delegation SHALL be designated by including id-kp-OCSPSigning in the extended key usage extension of the responder's certificate, which MUST be issued directly by the CA identified in the request. Systems relying on OCSP MUST detect and enforce this EKU value and MUST reject responses whose signing certificate fails the authorized responder criteria.
When a responder sends a 'revoked' response for a non-issued certificate, it MUST include the extended revoked definition extension (id-pkix-ocsp-extended-revoke), MUST specify revocation reason certificateHold (6), MUST specify revocationTime January 1 1970, and MUST NOT include a CRL references extension or CRL entry extensions.
A CA may deal with revocation checking of an authorized responder in three ways: include id-pkix-ocsp-nocheck (NULL value, SHOULD be non-critical) to allow the client to trust the responder for the certificate's lifetime; specify CRL Distribution Points or AIA for normal revocation checking; or leave revocation checking to client local policy.
An OCSP request contains a protocol version, service request, target certificate identifier (CertID), and optional extensions. Upon receipt, the responder checks whether the message is well-formed, whether it is configured for the requested service, and whether the request contains sufficient information.
Error responses (not signed) are defined for five cases: malformedRequest, internalError, tryLater, sigRequired, and unauthorized. The 'unauthorized' response covers cases where the client is not authorized or the server cannot respond authoritatively.
OCSP defines three definitive certificate status values: 'good' (no revocation known for the serial number within its validity interval), 'revoked' (revoked permanently or on certificateHold, or optionally for non-issued certificates), and 'unknown' (responder does not recognize the issuer or certificate).
Responses define four time fields: thisUpdate (most recent time the status was known correct), nextUpdate (time by which newer information will be available), producedAt (time the responder signed the response), and revocationTime (time the certificate was revoked or placed on hold).
The CRL References extension (id-pkix-ocsp-crl, OID { id-pkix-ocsp 3 }) allows a responder to indicate the CRL on which a revoked or onHold certificate appears, using CrlID containing optional crlUrl (IA5String), crlNum (INTEGER), and crlTime (GeneralizedTime) as singleExtensions.
The Extended Revoked Definition extension (id-pkix-ocsp-extended-revoke, OID { id-pkix-ocsp 9 }, value NULL, MUST NOT be critical) signals that the responder supports the 'revoked' status for non-issued certificates. It MUST appear in responseExtensions (not singleExtensions) whenever a 'revoked' response is given for a non-issued certificate.
The Nonce extension (id-pkix-ocsp-nonce, OID { id-pkix-ocsp 2 }, value OCTET STRING) cryptographically binds a request and response to prevent replay attacks; it is included in requestExtensions and mirrored in responseExtensions.
The Preferred Signature Algorithms extension (id-pkix-ocsp-pref-sig-algs, OID { id-pkix-ocsp 8 }) allows clients to declare ordered preferred signature algorithms in requestExtensions. Each PreferredSignatureAlgorithm contains a sigIdentifier and optional pubKeyAlgIdentifier (SMIMECapability) for specifying key parameters such as elliptic curve.
IANA updated the 'Application Media Types' registry references for application/ocsp-request (file extension .ORQ) and application/ocsp-response (file extension .ORS) to point to RFC 6960, which obsoletes RFC 2560.
Precomputed OCSP responses enable replay attacks: an attacker can replay a cached 'good' response after a certificate has been revoked but before nextUpdate expires. Deployments must carefully weigh the operational benefits of response pre-production against this replay risk.
Returning 'revoked' for non-issued certificates allows an attacker to predict or guess a serial number that will be issued and pre-obtain a revocation response. CAs using sequential serial numbers are especially vulnerable; using random high-entropy serial numbers mitigates the risk. The certificateHold reason code avoids permanently blocking a serial number.
The preferred signature algorithms mechanism is not protected against a man-in-the-middle downgrade attack. This is accepted because the responder MUST NOT sign with weak algorithms even if requested, and clients MAY independently reject responses that do not meet their cryptographic strength criteria.
Unsigned error responses expose OCSP to denial-of-service attacks where an attacker injects false error messages. Additionally, producing cryptographic signatures on every query is computationally expensive, exacerbating flood-of-queries DoS. Algorithm agility extensions slightly increase the DoS surface by allowing clients to request unsupported algorithms.
BasicOCSPResponse is a SEQUENCE containing tbsResponseData (ResponseData), signatureAlgorithm (AlgorithmIdentifier), signature (BIT STRING computed over hash of DER-encoded ResponseData), and optional certs. ResponseData includes version, responderID (byName or byKey SHA-1 hash), producedAt, SEQUENCE OF SingleResponse, and optional responseExtensions.
CertID is a SEQUENCE with hashAlgorithm (AlgorithmIdentifier), issuerNameHash (OCTET STRING, hash of issuer DN over DER encoding), issuerKeyHash (OCTET STRING, hash of issuer public key value excluding tag and length), and serialNumber (CertificateSerialNumber).
OCSPRequest is a SEQUENCE containing a TBSRequest (with optional version DEFAULT v1, optional requestorName, SEQUENCE OF Request, and optional requestExtensions) and an optional Signature (containing signatureAlgorithm, BIT STRING signature, and optional certificate chain).
OCSPResponse is a SEQUENCE of responseStatus (OCSPResponseStatus ENUMERATED: successful=0, malformedRequest=1, internalError=2, tryLater=3, sigRequired=5, unauthorized=6) and optional responseBytes (SEQUENCE of responseType OID and response OCTET STRING).
SingleResponse is a SEQUENCE containing certID (CertID), certStatus (CHOICE: good [0] IMPLICIT NULL, revoked [1] IMPLICIT RevokedInfo, unknown [2] IMPLICIT UnknownInfo), thisUpdate (GeneralizedTime), optional nextUpdate, and optional singleExtensions.