A CRL is an object which contains the list of serial numbers of certificates which have been revoked by a given CA. It is a signed object; the CRL issuer is usually the CA itself (with the same key) but this power can be delegated.
An OCSP response is what an OCSP responder returns when it receives a request about the revocation status of a certificate. The request / response protocol is specified in RFC 2560. The responses themselves are signed by the responder and they can have an independent life; this means that a given OCSP response can be considered as a specialized CRL which talks about a single certificate.
During certificate validation, the verifier (e.g. a Web browser, when validating the server's certificate) must build a chain of certificate, from one of its trust anchor (aka root certificates), verify all the signatures and names and extensions, and then proceeds with ascertaining the revocation status of each certificate in the chain. This last step entails obtaining CRL and/or OCSP responses, validating them (which means verifying the signatures on them), and reading their contents. This raises two distinct types of question:
- How does a verifier check that a CRL or OCSP response is genuine and up-to-date and really applies to the certificate at hand ?
- How does a verifier obtain the CRL or OCSP response in the first place ?
CRL / OCSP match with a certificate
Let's concentrate on the following setup: the verifier wants to obtain the revocation status of certificate T (as "target"). He has already built and verified a chain of certificates which ends with CA certificate C followed by T, which means that the signature on T matches the public key in C. Also, the revocation status of C has been verified, and it is now T which the verifier is interested in. T can be an end-entity certificate (e.g. the SSL server's certificate) or another CA certificate as part of a longer chain, which extends beyond T.
A CRL is signed; who signs it is a matter of a subtle distinction between X.509 and its PKIX interpretation in the context of the Internet. For the "original" X.509, a CRL is valid if it is signed by an entity who has a valid certificate and bears the same Distinguished Name as the CA. This works well if the CRL is signed by the same public key than T, i.e. the key of the CA C: at that point, C is a fully validated certificate so its public key can be "trusted" (the verifier is reasonably sure that the public key is really owned by an entity which goes under the name given in C's subjectDN field). However, it could be any other certificate with that name, and located at the end of a valid chain of its own (which may imply more path building, validation and processing of CRL). In X.509, distinguished names are everything, because X.509 was meant for the Directory, the worldwide LDAP-like server aggregate where everything is uniquely referenced by it distinguished name.
PKIX, the working group which deals with the Internet, has noticed that the Directory, marvelous as it may be, shares some characteristics with mythical beasts like the Mokèlé-mbèmbé, specifically that it does not appear to exist at all (at least, no confirmed sighting has been reported). Correspondingly, PKIX enforces a restriction to keep trouble contained: the certificate of the CRL issuer must be at the end of a path which begins with the same trust anchor as the path which ends with T. This should avoid trans-root issues when two distinct CA which do not know each other ended up using the same distinguished names (they could have noticed the issue right away if they had worked in the context of the Directory, if it had existed). This specific point is in RFC 5280, section 6.3.3, step (f).
The role of CRL issuer can be delegated, in which case the distinguished name of the CRL issuer is found in the CRL Distribution Points extension in T itself, and a matching Issuing Distribution Point extension is found in the CRL.
For OCSP responses, a similar system is used. The OCSP response may be signed by the CA itself (with the key in C); or there may be a dedicated issuer. Things are more constrained there: when there is a dedicated issuer, it must have a certificate which is directly issued by C itself, and bearing a specific extension which marks it as an OCSP responder (Extended Key Usage with the id-kp-OCSPSigning OID, see section 4.2.2.2 of RFC 2560). The certificate for that responder can be attached to the OCSP response itself (outside of the signed area, but encoded within the same blob nonetheless).
The important point is that it does not matter how the CRL or OCSP response were obtained: they are signed object, verifying the signatures and all the name matching and extension contents is sufficient. The object themselves can travel over TCP connections, emails, USB keys, caravans of camels, learned by heart and declaimed by a Shakespearian actor, whatever. The signature abstracts these details away. Certificates, CRL, OCSP responses cannot be "manipulated" without invalidating the signature.
CRL and OCSP responses have validity dates. They both have a thisUpdate field which tells when they were issued (formally, the date at which the information they contain was gathered). They also have a nextUpdate field which is the date before which a newer version should be issued; thus, it serves as a kind of expiry date. It is expected that verifiers cache CRL and OCSP responses, using these dates to know whether the cached version is still usable, or a new one should be obtained.
How to locate CRL and OCSP responses
The way a CRL or OCSP response is distributed is not important for security, but, of course, a verifier cannot guess URL out of thin air. The URL at which CRL can be downloaded is encoded in the CRL Distribution Points extension of the certificate T (this extension has two roles: a validating role for delegation of CRL issuance power, and a descriptive role to give pointers to locations where the actual CRL could be downloaded). http:// URL are common, but also ldap:// URL (especially in closed environment like enterprise networks). An https:// URL for CRL download can lead to a loop (since the download entails validating the certificate of another SSL server) hence it will tend not to be supported well, or at all (Windows will not follow such URL).
Similarly, the URL at which an OCSP responder can be found is in the Authority Information Access extension in certificate T.
These URL are indicative only; the verifier can use any CRL or OCSP response it could obtain, regardless of its provenance, provided that all the signatures are verified. Since CRL and OCSP responses have a non-negligible lifetime, it makes sense to cache and reuse them. OCSP stapling is a way for a SSL server to obtain OCSP responses for his own certificate, and provide them to the client, under the assumption that the client may need them. This makes the whole process more efficient: the client does not have to open extra connections to get the OCSP responses itself, and the same OCSP response can be sent by the server to all clients within a given time frame. One way to see it is that the SSL server acts as a Web proxy for the purpose of downloading OCSP responses.
OCSP stapling is entirely up to the SSL server; the contents of the certificates and OCSP responses is unaffected. The CA or the OCSP responder need not be aware that stapling occurs at all.
"Removing" the OCSP stapling flag from the handshake would break the Finished messages at the end of the handshake, so this is not feasible for the attacker, unless this would allow him to break the whole handshake before the end. However, it does not: the lack of OCSP stapling does not mean that the client will not ascertain revocation status; it just means that the client will be on his own, and will have to obtain the CRL or OCSP responses by itself.
The unfortunate thing about OCSP stapling is that it is not yet widely supported. The idea is sound, though. Its security implications is that, with stapling, a SSL server has a powerful argument to convince the Web browser to actually do its job and not skip revocation status checks altogether, like many Web browsers are unfortunately prone to do (things change in that matter, but slowly).
Note: CRL / OCSP response lifetime usually ranges from a few minutes to a few days. The dates are verified with regards to the client notion of time; clients with out-of-date clocks can run into trouble.
