OCSP and CRL Scalability

One design consideration that has received a lot of attention over the years in the PKI world is scalability surrounding CRLs. As we have discussed, CRLs were born of the need to tell cryptographic endpoints which public key certificates that they are using have expired or have been revoked by the CA or CA administrator. We have further discussed that CRLs are periodically issued to cryptographic endpoints by CRL issuers, and stored locally on the cryptographic endpoint itself. This presents problems on memory-constrained endpoints like workstations and network nodes. This problem begins to penetrate all areas of the PKI design as the size of the CRL grows and higher-end cryptographic devices are now struggling to accommodate the storage of the large CRL. The IETF's PKIX working group has drafted proposals and RFCs for several alternative methods that would eliminate the need to store the CRL locally on the cryptographic endpoint itself. One of most widely used protocols is the Online Certificate Status Protocol.

Tip

PKIX has defined many protocols to address PKI scalability issues surrounding CRL storage and other design topics. For more information on the PKIX and its initiatives you can view their charter at http://www.ietf.org/html.charters/pkix-charter.html.

OCSP

OCSP was developed to provide routers with the ability to check for revoked certificates quicker and more frequently than they could when following the standard CRL-checking format. In an OCSP arrangement, cryptographic endpoints act as OCSP clients, and the CRL issuer typically acts as the OCSP responder. The client gets CRL information from the OCSP responder through the following exchange:

1.	The OCSP client receives a certificate from another peer.
2.	The OCSP client sends an OCSP request to the OCSP server for the validity of the certificate that it just received.
3.	The OCSP server checks the signature within the OSCP request to see if the OCSP request is well formed and that it contains the information it needs to formulate a response.
4.	The OCSP server crafts an OCSP response message containing one of three messages: Good Revoked Unknown
5.	The OCSP responder digitally signs the response and forwards it to the OCSP client.
6.	The OCSP client receives the OCSP response message, and verifies the digital signature.
7.	The OCSP client uses the OCSP response message to determine the validity of the certificate received in Step 1.

Note

Cisco IOS allocates 64k of memory for CRL processing. This is adequate for the majority of CRL sizes. However, for abnormally large CRLs, alternatives to standard CRL checking, such as OCSP, must be explored.

The preceding exchange provides a scalable alternative to periodically downloading the full CRL from a CRL issuer. OCSP messages are ensured to be authentic and with integrity, since the CRL issuer digitally signs all OCSP responses.