I'm trying to get a greater understanding of the advantages of OCSP and have been reading Brian's book and the following 'Ask the DS Team' blog entry http://blogs.technet.com/b/askds/archive/2009/06/24/implementing-an-ocsp-responder-part-i-introducing-ocsp.aspx As far as I can ascertain, when a client sends a request to an OCSP responder, the process seems to be: 1. Is there a response already cached at the responder? If so return the response. 2. If a response is not cached, check the local copy of the relevant CRL and return the response. 3. If there is no local copy of the CRL (or it has expired?), retrieve the CRL from the CDP location and return the response to the client. If this is the process, I have a couple of questions: 1. In caching a response at the responder, does the cache only contain revoked certificates? I was thinking in terms of DNS caching where a negative response is cached. Is the fact that a certificate is valid cached, or only the fact that it is revoked? 2. If the copy of the CRL that is local to the responder is checked, this may not contain the latest revocation information, as I'm assuming that the responder will only go and get a new copy of the CRL when the old one has expired...or can the CRL be downloaded on a timed basis? OCSP seems to be offered as a solution to the latency problems associated with using CRLs, i.e. the time between a certificate being revoked and a relying party being notified of the revovation. However, if the responses are coming from CRLs anyway, is this not the lowest common denominator, so the latency issues still exist? Steve G

Hi, Yes, as far as I know, the latency still exists. When a certificate is issued, it is expected to be in use for its entire validity period. The benefit of caching CRLs locally is that CryptoAPI will always look for a cached copy first to avoid traversing the network and introducing latency in the revocation status checking. Under the circumstances that we need to revoke a certificate and force it to take effect immediately, we need to manually revoke the certificate, publish the latest CRL and clear the local cache. The OCSP responder uses the Base CRL and Delta CRL for determining revocation status. So, the certificate would need to be revoked and a new CRL published. Based on my understanding, the OCSP responder caches the CRL like any other client would. So you would then need to wait for the CRL to be expired, before the Responder would fetch a new CRL. You can also use certutil to clear the cache as well. If the concern is providing more current revocation information, you could configure validity period of the Delta CRL to be a short time period such as an hour. http://social.technet.microsoft.com/Forums/en-US/winserversecurity/thread/e78a4660-10fa-4641-90cc-583b60c868ab?prof=required This posting is provided "AS IS" with no warranties, and confers no rights. Please remember to click Mark as Answer on the post that helps you, and to click Unmark as Answer if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

Thanks, Joson. That tallies with what I was beginning to suspect. Steve G

Having just explored Revocation configuration on a 2008 R2 OCSP responder, I see there is a tick box for either checking CRL's based on their validity periods, or entering a time in minutes for the CRL refresh interval. Does this solve the latency problem? I've not had time to check in the lab yet but on the surface it would seem to (so long as a new CRL was published following the revocation of a certificate). DouksDouks