X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP
obsoleted by
- rfc-6960 — X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP
updated by
- rfc-6277 — Online Certificate Status Protocol Algorithm Agility
Extracted elements (31)
CertID includes both issuerNameHash and issuerKeyHash because two CAs may choose identical Names (uniqueness is only a recommendation, not enforceable), but two CAs will never share the same public key unless they deliberately share their private key or one is compromised.
OCSP responders MAY pre-produce signed responses to reduce per-request cryptographic overhead. Pre-produced responses use thisUpdate to record when status was known correct and nextUpdate to bound the validity window, enabling caching while preserving timeliness semantics.
The protocol is transport-independent; actual message formatting varies by transport (HTTP, SMTP, LDAP, etc.). Appendix A specifies HTTP binding; the core ASN.1 structures are defined independently of transport.
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 requester, or a CA Designated Responder holding a specially marked certificate issued directly by the CA.
CAs that support OCSP SHALL provide the capability to include the AuthorityInfoAccess extension in certificates that can be checked using OCSP, and MUST provide for inclusion of a URI accessLocation with the OID id-ad-ocsp for the accessMethod.
Clients requesting OCSP services SHALL be capable of processing responses signed with DSA keys as specified in RFC 2459 section 7.2.2. Clients SHOULD also be capable of processing RSA signatures. OCSP responders SHALL support the SHA1 hashing algorithm.
For HTTP transport, small OCSP requests (after encoding less than 255 bytes) MAY use GET to enable HTTP caching; requests larger than 255 bytes SHOULD use POST. Where privacy is required, OCSP transactions MAY be protected using TLS/SSL.
If an OCSP request is signed, the requestor SHALL specify its name in the requestorName field. The signature is computed over the tbsRequest structure.
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.
OCSP signing delegation SHALL be designated by the inclusion of id-kp-OCSPSigning in an extendedKeyUsage extension in the OCSP signer's certificate, which MUST be issued directly by the CA that issued the certificate in question.
Prior to accepting a signed response as valid, OCSP clients SHALL confirm: (1) the certificate in the response matches the request; (2) the signature is valid; (3) the signer identity matches the intended recipient; (4) the signer is authorized; (5) thisUpdate is sufficiently recent; (6) nextUpdate, when present, is greater than current time.
Responses whose nextUpdate value is earlier than local system time SHOULD be considered unreliable. Responses whose thisUpdate time is later than local system time SHOULD also be considered unreliable.
Systems relying on OCSP responses MUST reject the response if the certificate required to validate the signature fails to match a locally configured OCSP signing authority, be the CA's own certificate, or include id-ad-ocspSigning in an ExtendedKeyUsage and be issued by the CA.
The critical flag SHOULD NOT be set for any OCSP extensions. Unrecognized extensions MUST be ignored unless they have the critical flag set and are not understood.
Certificate status values defined by OCSP are 'good' (certificate is not revoked), 'revoked' (permanently or on hold, with optional CRLReason), and 'unknown' (responder does not know about the requested certificate).
Error response types (not signed): malformedRequest (request does not conform to OCSP syntax), internalError (inconsistent internal state — retry), tryLater (service temporarily unavailable), sigRequired (server requires signed request), unauthorized (client not authorized).
The archive cutoff extension (id-pkix-ocsp-archive-cutoff, OID { id-pkix-ocsp 6 }, syntax GeneralizedTime) allows a responder to indicate how far back its historical revocation records extend, supporting proof that signatures were reliable at a past date.
The id-pkix-ocsp-nocheck extension (OID { id-pkix-ocsp 5 }) in an authorized responder's certificate signals that OCSP clients can trust the responder for the certificate's lifetime without separately checking its revocation status.
The nonce extension (id-pkix-ocsp-nonce, OID { id-pkix-ocsp 2 }) cryptographically binds a request and response to prevent replay attacks; it is included in requestExtensions and reflected in responseExtensions.
Three time fields convey response validity: thisUpdate (time at which the indicated status is known correct), nextUpdate (time at or before which newer status will be available), and producedAt (time the OCSP responder signed the response). Absence of nextUpdate means newer revocation information is continuously available.
MIME type application/ocsp-request registered with IANA for binary-encoded DER OCSP request messages; file extension .ORQ. Used by OCSP clients to POST requests over HTTP.
MIME type application/ocsp-response registered with IANA for binary-encoded DER OCSP response messages; file extension .ORS. Used by OCSP servers to return responses over HTTP.
OCSP is vulnerable to denial-of-service via query floods, exacerbated by the cost of cryptographic signing per response. Unsigned error responses open a secondary DoS vector where an attacker sends false error messages to prevent certificate validation.
OCSP requests do not contain the responder they are directed to, allowing an attacker to replay a captured request to any number of OCSP responders. Reliance on HTTP caching may yield unexpected results if intermediate servers are misconfigured.
Use of precomputed responses enables replay attacks: an old 'good' response may be replayed after a certificate has been revoked but before the response expires. Deployments must weigh the performance benefit of precomputed responses against this replay risk.
BasicOCSPResponse is an ASN.1 SEQUENCE of ResponseData, signatureAlgorithm (AlgorithmIdentifier), signature (BIT STRING computed over hash of DER-encoded ResponseData), and optional certs. ResponseData includes version, responderID, producedAt (GeneralizedTime), responses (SEQUENCE OF SingleResponse), and optional extensions.
CertID is an ASN.1 SEQUENCE containing hashAlgorithm (AlgorithmIdentifier), issuerNameHash (OCTET STRING — hash of issuer's DN DER encoding), issuerKeyHash (OCTET STRING — hash of issuer's public key value excluding tag/length), and serialNumber (CertificateSerialNumber).
OCSPRequest is an ASN.1 SEQUENCE of TBSRequest (version, optional requestorName, requestList, optional requestExtensions) and an optional Signature (signatureAlgorithm, BIT STRING, optional certs). Data to be signed is DER-encoded per X.690.
OCSPResponse is an ASN.1 SEQUENCE of responseStatus (OCSPResponseStatus ENUMERATED: successful(0), malformedRequest(1), internalError(2), tryLater(3), sigRequired(5), unauthorized(6)) and optional responseBytes. ResponseBytes are not set when responseStatus indicates an error.
ResponderID is a CHOICE between byName [1] (Name) and byKey [2] (KeyHash, an OCTET STRING holding the SHA-1 hash of the responder's public key excluding tag and length fields).
SingleResponse contains certID (CertID), certStatus (CertStatus CHOICE of good [0] NULL, revoked [1] RevokedInfo, or unknown [2] NULL), thisUpdate (GeneralizedTime), optional nextUpdate (GeneralizedTime), and optional singleExtensions.