OCSP
securityFull Name: Online Certificate Status Protocol
Definition
The Online Certificate Status Protocol (OCSP), defined in RFC 6960, is a protocol for determining the revocation status of an X.509 digital certificate in real-time. Unlike Certificate Revocation Lists (CRLs) that require downloading a potentially large list of all revoked certificates, OCSP allows a client to query the status of a specific certificate by sending a request to an OCSP responder, which returns a signed response indicating whether the certificate is valid, revoked, or unknown. In the EUDI Wallet ecosystem, OCSP is relevant for validating the PKI infrastructure that underpins issuer certificates, trust framework components, and the mTLS connections between backend services.
How OCSP Works
The OCSP protocol follows a simple request-response pattern. When a client needs to verify a certificate's status (for example, when establishing a TLS connection to a credential issuer), it sends an OCSP request to the responder URL specified in the certificate's Authority Information Access (AIA) extension. The request contains the certificate serial number and the issuer's identifier.
The OCSP responder -- typically operated by the Certificate Authority (CA) that issued the certificate -- looks up the certificate status in its database and returns a signed response. The response includes one of three statuses: "good" (the certificate is valid and not revoked), "revoked" (the certificate has been revoked, with the revocation reason and date), or "unknown" (the responder does not have information about this certificate).
The response is signed by the OCSP responder's key, allowing the client to verify its authenticity. Responses include a "thisUpdate" timestamp (when the status was confirmed) and often a "nextUpdate" timestamp (until when the response can be cached), enabling clients to cache responses and reduce query frequency.
For EUDI Wallet infrastructure, OCSP validation ensures that if a credential issuer's certificate is revoked (for example, due to a security breach), verifiers will detect this revocation promptly rather than continuing to trust credentials signed with a compromised key.
OCSP Stapling for Performance and Privacy
Standard OCSP has two significant drawbacks: it adds latency (an extra network round-trip to the OCSP responder) and it has privacy implications (the OCSP responder learns which certificates clients are checking, revealing browsing/connection patterns). OCSP Stapling (defined in RFC 6066 as the TLS Certificate Status Request extension) addresses both issues.
With OCSP Stapling, the server periodically fetches its own OCSP response from the responder and includes ("staples") this response in the TLS handshake. The client receives the certificate and its OCSP status simultaneously, eliminating the need for a separate query. Since the response is signed by the CA, the server cannot forge it, and the client can verify its authenticity.
EUDI Wallet infrastructure components (issuer endpoints, verifier services, trust registry APIs) should enable OCSP stapling on their TLS configurations. This ensures that wallet applications and verifier systems can validate certificate status without additional latency or privacy leaks. OCSP Must-Staple (a certificate extension requiring the server to always staple a response) provides the strongest guarantee.
For load balancers fronting EUDI Wallet services, OCSP stapling is typically configured at the load balancer level, which handles TLS termination. The load balancer caches and refreshes OCSP responses, providing stapled responses to all incoming connections without requiring each backend service to manage its own OCSP stapling.
From OCSP to Credential Status Lists
While OCSP is well-suited for certificate revocation checking (where the total number of certificates per CA is manageable), it does not scale well for credential revocation in the EUDI Wallet ecosystem. A single Member State may issue tens of millions of verifiable credentials, and checking each credential's revocation status via individual OCSP queries would create enormous load on the responder infrastructure.
The EUDI Wallet Architecture Reference Framework instead uses Status List tokens for credential revocation. A Status List is a compact bitfield where each bit represents the revocation status of one credential. Verifiers download the entire status list (typically kilobytes in size) and check the bit corresponding to the credential they are verifying. This is dramatically more efficient than per-credential OCSP queries and can be cached effectively.
However, OCSP and Status Lists serve complementary purposes. OCSP is used at the PKI/infrastructure level (validating issuer certificates, verifier certificates, trust framework component certificates), while Status Lists operate at the credential level (checking if a specific identity credential has been revoked). Both are necessary for a complete trust verification chain.
For offline verification scenarios, neither OCSP nor online Status List queries are available. Verifiers can cache OCSP responses (within their nextUpdate validity window) and cache Status Lists for a defined freshness period. The acceptable cache duration is a policy decision balancing revocation timeliness against offline usability -- the EUDI Wallet framework defines maximum freshness intervals for different credential types.