A security architect is deploying a public key infrastructure (PKI) and wants to ensure that certificate revocation status is verified efficiently without relying on a centralized CRL distribution point. Which technique should be used?
OCSP Stapling is an efficient method for web servers to provide clients with the revocation status of their own SSL/TLS certificates during the TLS handshake. The server periodically queries the Certificate Authority's (CA) Online Certificate Status Protocol (OCSP) responder for its certificate's status, caches the signed response, and "staples" it to the certificate sent to the client. This significantly improves privacy and performance by eliminating the need for each client to directly query the OCSP responder, reducing latency and server load.
Why this answer
OCSP Stapling allows the server to obtain a signed, time-stamped OCSP response from the CA and present it to clients during the TLS handshake, so clients do not need to contact the OCSP responder directly. This eliminates the latency and privacy concerns of real-time OCSP lookups and avoids reliance on a centralized CRL distribution point. It is the standard technique for efficient, decentralized revocation checking.
Exam trap
CISSP often tests the difference between OCSP Stapling (server-provided, cached revocation proof) and plain OCSP (client-to-responder lookup) — candidates pick Certificate Transparency or pinning because they sound security-related, but only stapling provides efficient decentralized revocation verification.
How to eliminate wrong answers
Option A is wrong because Certificate Transparency Logs are append-only public logs used to detect mis-issued certificates; they do not provide revocation status and are not a substitute for CRL or OCSP. Option C is wrong because certificate pinning hardcodes a specific certificate or public key in the client, which prevents use of fraudulent certs but does not verify revocation status and can break on legitimate cert rotation. Option D is wrong because self-signed certificates are not issued by a trusted CA, so they bypass the PKI trust model entirely and provide no revocation mechanism — they are unsuitable for public PKI deployments.