Subject: Re: Candidate for moving OCSP to a Draft Standard

From: [email-masked] (Peter Gutmann)
Date: Sat, 9 Feb 2002 07:41:55 +1300 (NZDT)

"David P. Kemp" <[email-masked]> writes:

>>The reasoning as I recall was that OCSP shouldn't include facilities which
>>aren't bug-compatible with CRLs.  Since CRLs can only provide a negative
>>response, and even that only for some cases of invalid certs, OCSP doesn't
>>include a straighforward yes/no indication.
>
>Say what?  CRLs provide positive and negative responses, and the positive
>response is optimized down to 0 bytes.

They don't provide a positive response, only a negative one.  If a cert is ever
rendered invalid for *any* reason other than CA revocation, a CRL can't
indicate this.  Examples of this include the fact that it hasn't become valid
yet or has expired and the client doesn't realise because its time is out
(standard practice in the Windows world, the worst I've seen was a system with
its clock out by several decades), it wasn't regarded as being issued by the CA
and therefore can't be revoked (which can occur in CMP, see the postings about
a neverValid CRL status from a while back), or a number of other situations.

The problem with CRLs is that they ask entirely the wrong question - "Has this
been revoked?" - when what's really of interest is an answer to the question
"Is this currently valid?".  This can't really be fixed, because that's the
only question a blacklist is capable of answering.

>The reason OCSP can't say that a cert is valid has nothing to do with CRLs.
>It's crippled by the fact that the request does not include a cert, so the
>responder can't validate the signature unless it fetches the cert itself.
>Presumably the OCSP authors made a conscious decision not to require the
>responder to validate certification paths before providing a response.

It doesn't need to validate anything.  That's why my text summary went to such
pains to point out that it was strictly an "account in good standing" query.
The CA acknowledges that it issued the cert, and that it's currently in good
standing.  That's all.  There's no validation, path checking, or anything else.

>>(IMHO any poor guy who's stuck with feeding their online status service from
>  offline CRLs has bigger things to worry about than this...).
>
>Speaking as one such poor guy :-), what's the problem?

The fact that you're feeding a real-time status process from a source updated
hourly or daily or whatever (I've seen CAs which issue CRLs in half-day or
full-day intervals, or which guarantee a CRL age of not more than 24 hours, 8
hours average-case).

>What could be more elegant than having your LAN-based OCSP server replicate
>the PKI revocation database by fetching delta CRLs from the central server
>every 15 minutes?

What could be more sensible than having your OCSP responder process queries by
consulting the central server directly?  If I'm using certs for financial
transaction authorisation then it may be elegant to introduce a 15-minute delay
in order to give the crooks a sporting chance, but it's not financially
satisfying in the long run :-).

Why do CRLs even need to feature in the process, except to highlight their
deficiencies?  Someone (probably the aforementioned Lynn Wheeler) once said
that the only reason you'd use an offline mechanism to feed online queries is
to point out how broken it is.

Peter.

---

From: "David P. Kemp" <[email-masked]>
Date: Fri, 08 Feb 2002 16:37:21 -0500

> a neverValid CRL status from a while back), or a number of other situations.

A bank or someone with money at stake on certificate validation can be
assumed to have a clock in sync with the rest of the world - Darwin
ensures
that.  So you don't need OCSP or CRLs at all to tell that a certificate
is outside it's validity period, if the answer matters.

If a remote issuance process requires an acceptance receipt before
considering the certificate valid, then the certificate can certainly be
revoked by the CA if the subscriber doesn't acknowledge receipt.
How can you say "can't be revoked" in the same sentence with the
neverValid revocation reason?

> What could be more sensible than having your OCSP responder process
> queries by consulting the central server directly?  If I'm using
> certs for financial transaction authorisation then it may be elegant
> to introduce a 15-minute delay in order to give the crooks a sporting
> chance, but it's not financially satisfying in the long run :-).

That is my point, that CRLs *are* consulting the central server
directly,
using fewer bytes than with an Oracle replication process, an http or
OCSP
query, or any other general-purpose back-end mechanism you might
suggest.
If you don't like 15 minute delay, then make it a 15 second delay, or
one
second. The CA can certainly generate one delta CRL every second and
transmit (or multicast) it to 5000 OCSP responders using less resources
than it would take to update the same 5000 responders within one second
using some other mechanism.

> to point out how broken it is.

The fallacy with that reasoning is that CRLs aren't inherently "offline"
any more than a web page is "offline".  Information can be delivered to
a recipient, and cached by that recipient.  If the recipient chooses to
cache web pages or CRLs or OCSP responses, then the recipient is
choosing to be offline. If the recipient never caches, then the
recipient is online.

Source information such as a web cam image, a stock market quote, or a
revocation status is also neither "offline" nor "online", it is only
updated with a certain frequency.  You don't like CAs who update
their CRLs every 24 hours, then suggest that they update them every
15 seconds (to a select group of redistributors, not every end user)
instead.  If I were a CA bidding on a Service Level Agreement to provide
15-second revocation freshness and 1 second response time for 1 million
users, I would bid less to do it using delta CRLs than using Oracle
or Sabre or whatever acceptance system Lynn has in mind.

---

From: Michael Ströder <[email-masked]>
Date: Wed, 20 Feb 2002 22:55:00 +0100

"David P. Kemp" wrote:
> assumed to have a clock in sync with the rest of the world

The bank itself, yes. But not every client. There are always two
ends.

> one second. The CA can certainly generate one delta CRL every second and

You're certainly right that distributing CRLs is kind of a secured
replication mechanism and I would concur that it's less data bloat
than some other DB access protocols.

But since a CRL has to be signed by the CA's private key it depends
very much on the (physical) protection of the private key how fast
you can issue a new CRL after getting knowledge about that a
certificate must be revoked.

Ciao, Michael.