Subject: OCSP vs. CRLs

From: "Bob Jueneman" <[email-masked]>
Date: Wed, 23 Aug 2000 12:11:53 -0600

As one of the original proponents (with Sead Muftic) of an on-line document (not certificate) validation service, I'd like to support Steve's assertion that "it depends" on whether OCSP is "better" than CRLs.

I contend that it is very important to carefully consider the risk, the computational load imposed on the server, the "freshness" of either the CRL or OCSP response, the availability of caching, and most importantly, the availability of full-time available connections in coming to that decision.

If updated CRLs are reliably made available to anyone who inquires as soon as the decision to revoke a certificate is made, then I would argue that they are nearly as good as OCSP.  (Not quite as good, because OCSP at least provides the option of including the hash of the document in question, which avoids all sorts of time-stamping issues. But it isn't clear that OCSP in fact does that.)

However, the overhead of OCSP in terms of both server computational load and bandwidth makes it completely ridiculous to even consider for certain applications.  For example, suppose that every .EXE and .DLL in Windows was signed by Microsoft, and that the loader validated that signature every time the module  was invoked.  Obviously this would be helpful in preventing certain classes of viruses, right?  And arguably, at least, it would be desirable for the certificate chain to be checked to make sure that the signing key hadn't been compromised, or that Microsoft was no longer Microsoft, but was now a Baby Bill.

But going back to the CA every time a module was invoked would obviously bring the user's computer, the Internet, and VeriSign to its knees, in that order.  OK, so maybe we don't check it every time -- maybe just when booting up, or every 24 hours.  In other words, "I didn't mean THAT real-time!"  But in that case, a CRL would do equally well, and in fact better, since CRLS can be cached locally in any of a number of different ways.

Now consider the case of the Navy, steaming around the ocean during either peacetime or wartime.  On a carrier, there are lots of sailors, and they may need to either encrypt or sign e-mail.  They may also receive e-mail from home, or from shore-based installations.  But in general, the CAs are not part of the fleet, they are in San Diego, or Norfolk, or at Ft. Meade, or somewhere else back on shore.

Do you suppose that those ships would be willing to waste their very precious bandwidth going back to shore via OCSP to revalidate the certificate status of say the Chief of Naval Operations, if he sends out a message or order to everyone in the fleet?  Or to validate the certificate of someone on-board that ship? I certainly don't think so.  Instead, a cached CRL that is updated once a day or even once a week would be perfectly adequate, and highly preferable.

There are many other instances where the requirement for up-to-the-nanosecond validation of a certificate, or even a particular transaction, is simply not justified.  In fact, given all of the other safeguards and legal back-stops that exist, the need for such verification is more likely NOT to be the case.

I'm not saying that OCSP is of no value, nor am I saying that CRLs are invariable superior.  Or vice versa.

"It depends."

Bob

>>> Stephen Kent <[email-masked]> 08/23/00 08:03AM >>>
Tom,

>Hello Ambarish,
>
>Thanks for your reply. I agree that OCSP services are by far better than
>CRLs.

I think this is an over generalization, i.e., OCSP is bettr in some 
cases, but not in all cases.

>In general, as everyone knows, a CRL is a batch job that updates a
>database over certain intervals. From an audit standpoint, one of the many
>issues with CRLs is that they can be beat. For example, it is very easy to
>perform any series of denial of service attacks against the server.

Which server? A directory?  A CRL has the advantage that it can be 
replicated at any numnber of servers, without imbuing these serves 
with trust (re integrity and authenticity).  While it is certainly 
true that one can engage in  a DoS attack against directories, the 
same is also true for OCSP servers. I don't think we have enough 
experience with both types of servers to determine if one is more 
susceptible than the other, as a class, or if it's just an issue of 
implementation and local management quality.

>This
>could cause longer than expected delays in the execution of the batch job
>or worse, prevent the batch job from running causing latent (or corrupted)
>CRL publishing.

Batch job?  Now it sounds like your talking about a CA preparing a 
CRL.  A CA component generating a CRL need not be online and thus 
need not be very susceptible to DoS attacks, so I'm puzzled by this 
line of reasoning.

>Also, if someone is savvy enough, they could also issue
>hundreds of back to back CRL job requests resulting in multiple jobs
>waiting on shared services again causing problematic CRLs. I know this may
>sound farfetched but they are risks to be considered.

CRL job requests?  I've been involved with the design of several CAs 
over time and none offered an external interface which could be 
manipulated inthe fashion you suggest.

>As you may guess I am not a proponent of CRLs for obvious reasons. I have
>heard claims by some that their products are OCSP compliant. In reality it
>is just a batch job publishing to a database but still they have inherent
>CRL batch job latency.

The latency issue re CRLs is a red herring, in almost all cases. The 
time required to generate a CRL is fairly small for almost any PKI of 
a reasonable size.  The external, non-technical factors associated 
with deciding that a compromise has occurred or that an attribute has 
changed and thus a cert should be revoked almost always swamp the CRL 
production activity.

>As for the CAM, I am not familiar enough with that to argue for or against
>its use. I do know however that the Xcert product has a non proprietary
>real time OCSP LDAP out of the box resulting in a more robust product. Note
>that the Sentry CA product can publish CRLs to non OCSP products to offer
>backwards compatibility when needed. Also, the Sentry product can import
>other vendors CRLs and place them in the real time OCSP LDAP.

Oh, OCSp and LDAP?  That combination suggests an DoS opportunity that 
might be the sum of the two server interfaces :-).

>Also one of the several reasons that Sentry CA was chosen was due to its
>ability to cross certify against other CAs (cross certification). It is
>very easy to setup trust to another company's CA allowing multiple CAs or
>PKI vendors within a central Sentry OCSP environment.

No more product endorsements, OK?

Steve