RFC 6960

X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP
Standards Track Obsoletes: RFC 2560
June 2013
RFC Library > PKI & Certificates > RFC 6960
Abstract: OCSP enables applications to determine the revocation status of an X.509 certificate in real-time, without downloading complete CRLs. It provides a lightweight, online alternative to CRL checking for certificate validation in TLS and IPsec deployments.
Canonical source: https://www.rfc-editor.org/rfc/rfc6960  |  IETF Datatracker

1. Introduction

▶

OCSP provides real-time certificate revocation checking. Instead of downloading potentially large CRLs, a relying party sends a compact OCSP request to a responder and receives a signed response indicating whether the certificate is good, revoked, or unknown.

TLS 1.3 supports OCSP stapling (status_request extension) where the TLS server includes a signed OCSP response in the handshake, eliminating the need for the client to contact the OCSP responder separately.

2. OCSP Request/Response

▶
Status Meaning Action
good Certificate is not revoked Accept certificate
revoked Certificate has been revoked Reject certificate, close connection
unknown Responder has no information Policy-dependent (soft-fail or hard-fail) 
  Relying Party (NF)           OCSP Responder
|                              |
|  OCSPRequest:                 |
|  [requestorName,]             |
|   requestList[               |
|     {hashAlgorithm,           |
|      issuerNameHash,          |
|      issuerKeyHash,           |
|      serialNumber}            |
|   ]                           |
|----------------------------->|
|                              |
|        OCSPResponse:         |
|        responseStatus,       |
|        responseBytes{        |
|          certStatus: good|   |
|            revoked|unknown,  |
|          thisUpdate,         |
|          nextUpdate,         |
|          signature           |
|        }                     |
|<-----------------------------|

3. OCSP Stapling

▶

OCSP stapling (TLS status_request extension, RFC 8446 §4.4.2.1) allows the TLS server to fetch and cache the OCSP response, then include it in the Certificate message during the handshake:

  • Server-side caching: Server periodically fetches OCSP response from responder
  • Included in TLS handshake: CertificateStatus message carries the signed OCSP response
  • Client benefits: No separate OCSP connection needed, reduced latency, improved privacy
  • Must-Staple: Certificate extension that requires stapled OCSP response — prevents fallback to no-check
5G SBI Recommendation: NFs acting as TLS servers SHOULD support OCSP stapling to provide real-time revocation status without requiring NF clients to contact OCSP responders, reducing external dependencies in the core network.

4. Responder Models

▶
  • CA-integrated: OCSP responder shares CA's certificate status database directly
  • Delegated responder: Separate responder with CA-issued OCSP signing certificate (id-kp-OCSPSigning EKU)
  • Authorized responder: Responder identified by issuer in AuthorityInfoAccess extension

5. Security Considerations

▶
  • OCSP responses MUST be signed — unsigned responses MUST be rejected
  • Replay protection via nonces (optional) or thisUpdate/nextUpdate time windows
  • Soft-fail (treating 'unknown' or OCSP unreachable as 'good') weakens revocation checking
  • OCSP responder availability is critical — responder outage can cause service disruption
  • Pre-generated (pre-signed) responses improve responder scalability but have freshness limits