I'm trying to decide on a certificate revocation strategy for a solution I'm designing (that will utilize Dogtag PKI, per customer request). The obvious choices seem to be using a CRL or using OCSP. I'm trying to understand the practical implications of both, and select one that can support this particular solution.

I think the primary gotcha here is that while clients will have occasional network access to the PKI infrastructure, they will also need to operate in an isolated lan capacity. In this use case, two clients need to be able to authenticate each other directly (including a check for certificate revocation by a central authority) without access to e.g. an OCSP responder.

  • Does one of these solutions (CRL/OCSP) lend itself better to cached/offline operation?
  • Is it correct to characterize a CRL as a blacklist and OCSP as a whitelist (that could be cached locally, perhaps piecemeal for known peers)?
  • Am I asking the wrong question? (Another suitable solution, perhaps, or another angle to approach the problem?)

OCSP is really just a different means to the same end: checking whether a certain certificate is revoked. Both can be considered a blacklist; with a CRL the client will grab the whole list and check for the individual cert itself, while with OCSP it's sending a request to get the status on an individual certificate without needing the download the full list.

OSCP is, as the name implies, an online protocol; it's not appropriate for caching. Using a CRL would be the way to go for offline operation; since they can get big and checks are needed rather frequently, most operating systems will keep a cache of CRLs that they've used recently (depends on the application being used, of course), which would pretty much fit the bill for what you're looking for. Beyond that, use whatever means necessary to get that CRL file around to the clients, and have the root cert list something for a CDP that they can access locally.

However, there are definite downsides. Obviously caching carries with it the risk of allowing a revoked certificate with an out-of-date CRL, or, on the opposite end, hitting bad timing on CRL expiration and have your cached CRL get thrown away before reconnecting to the network. Additionally, make sure the root cert doesn't list a delta CRL; that would shorten the effective lifetime of caching significantly by requiring a current copy of a short-lived delta for every check.

The lifetime of the CRL will be the biggest design consideration; you'll need to balance the need for the clients to have working copies at all times, with what delay is tolerable for a revoked cert to be guaranteed to be no longer trusted.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.