Agility Loop

In order to verify a certificate, a relying party must perform three operations:

• Ensure the certificate is issued from a trusted PKI
• Verify the certificate is not expired
• Check that the certificate has not been revoked by the issuing certificate authority (CA)

Trust is typically a simple matter of installing the Root CA for the PKI that a relying party would like to trust.  I say typically because although this is trivial when one PKI is involved, it is very quickly getting more complicated in a bridge enabled world.

Expiration is a time check against the relying party’s system clock.  There is always some variation in clock times, but most relying party applications have some wiggle in time checking.  Even if they don’t, a matter of a few minutes is really only important for highly valuable or sensitive transactions (and I don’t have time to get into signed and authoritative time sources).

Of the three, revocation seems to be the one that causes folks the most trouble, especially in larger PKIs like DoD.  There are two main revocation methods, with one additional emerging.

• Certificate Revocation Lists (CRLs) – CRLs are signed binary files that contain a listing of serial numbers and other information of certificates that have been revoked by an issuing CA.  Relying parties wishing to check revocation need to download the CRL and parse the file.  Each issuing CA issues a CRL (including the Root), so relying parties will likely need to retrieve multiple files.  These files can be cached according to how long they are valid (this value is in the CRL itself).  As your PKI grows, your CRLs grow along with you.
• Online Certificate Status Protocol (OCSP) – This is a HTTP request for the status of certificates.  The response from an OCSP server can contain more than one response.  Relying parties will need to make a OCSP call for every certificate that it checks.   Like CRLs, theses files can be cached.  However, the cache is somewhat less useful since it contains a small set of certificates.
• Server-based Certificate Validation Protocol (SCVP) – Although SCVP is a standard, support for the protocol is still emerging.  SCVP allows for out-sourced trust processing.  It is especially valuable in PKI interoperability scenarios.

So as an IT admistrator or application owner, what do you choose?

First and foremost this depends on the size of your PKI and the lifetime of your certificates.  If you are dealing with a smaller PKI and shorter lived certificates (say 10,000 users and one year certs) than most of your applications should be able to handle CRL downloads.  However, larger PKIs (50,000+ users and 3 years certs) need to consider different revocation checking methods for different scenarios.  Some PKIs have a series of CRLs over 100+ MBs!

For client applications, especially email, I typically recommend that OCSP be considered.  However, using OCSP means that your PKI has to have an OCSP server up and running 24×7x365.  If OCSP services are down, your uses will NOT be able to verify transactions (and they will get error message and then in turn call you).  Even if your PKI is outsourced, you may have to purchase OCSP client licenses.  Microsoft added support to Windows with Vista, and even then the client has limited functionality and configurability (although we have tested that newer OCSP server software now supports OCSP requests from Vista and 7).  Using CRLs for clients can get VERY messy.  Think of it this way, do you really want every email client in your domain pulling down upwards of 100+ MBs of files?

For server applications, it really depends on transaction volume.  Keep in mind that for every certificate your application needs to process, a revocation check needs to be performed.  For OCSP, this means a HTTP request to an OCSP server that may not be on the same network as your application.  So if you have a lot of users or transaction in your applicaiton, this could mean a lot of OCSP requests.  If CRLs are used, then you need only retrieve a CRL once every time it is produced (or less often if you desire) and cache it locally.  Keep in mind however that many web and applicaiton servers have fairly brittle CRL implementations.  Many administrators will create scripts that will allow them greater control over CRL downloads.

Next time I get the chance to post, I’m going to cover how PKIs make CRLs available, and what NOT to put into a CRL Distribution Point (CDP).  Yes…I know it is very exciting!