Re: [TLS] Certificate validation can of worms

["Kemp, David P." <[e-mail]>]

You are comparing apples and oranges - OCSP responses covering one or a few certificates vs. CRLs covering hundreds of thousands.  If you select a given number of subscribers per status structure, CRLs are more efficient than OCSP.  Alternately, if you select a given data structure size (4K, 16K, 64K), the number of subscribers covered by a CRL of that size is larger than the number covered by the same sized OCSP response, because the CRL uses a more efficient encoding.

The same server-vs-client fetch options apply to CRLs as OCSP.  However, only CRLs support delta coding, which saves significant bandwidth for bulk transfers (as a server validating many clients would need).

OCSP validation is not simpler, it simply uses a more verbose representation of the same information.



-----Original Message-----
From: TLS [mailto:[e-mail]] On Behalf Of Nico Williams
Sent: Saturday, April 05, 2014 5:01 PM
To: Watson Ladd
Cc: [e-mail]
Subject: Re: [TLS] Certificate validation can of worms

On Fri, Apr 04, 2014 at 10:15:39PM -0700, Watson Ladd wrote:
> On Fri, Apr 4, 2014 at 9:17 PM, Nico Williams <[e-mail]> wrote:
> > Let's take #2 first.  Here's two entrants:
> >
> > - x.509 naming is impossibly difficult to deal with (see RFC4514);
> >
> > - stapled OCSP is how it should have been from day one -- CRLs add a 
> > ton of complexity
> 
> You are ignoring the reason we have CRLs in the first place: stapled 
> OCSP assumes all devices are globally connected and so can get OCSP.

This is the off-line infrastructure argument.

If you have the same freshness policy for CRLs and [stapled] OCSP then you have the same on-line/off-line trade-off but with the on-line infrastructure access burden moved from the RP's shoulders to the presenter's.

In terms of mechanics, stapled OCSP Response validation is simpler than CRL checking, and its operational characteristics are *much* better (just ask the DoD).

-------------------------