Subject: RE: [OCSP] are several requests for different CAs at once valid ?

From: "Deacon, Alex" <[email-masked]>
Date: Mon, 15 Sep 2003 14:37:05 -0700

I have to agree with Ryan on this one.  Online does not necessarily mean
real time.  For example, there are many OCSP responders on the market that
get the revocation information from CRL's.  These responders are online, but
not real-time.
 
Anyway, the bottom line is this:  In order to provide OCSP services for very
large scale internet pki's (e.g. SSL and code signing CA's) in a *cost
effective* way, OCSP responses must be pregenerated, distributed and finally
cached through out the network (on clients, proxy's, server's, etc).  
 
Alex

-----Original Message-----
From: Ryan M. Hurst [mailto:[email-masked]]
Sent: Monday, September 15, 2003 8:49 AM
To: Peter Gutmann; [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: RE: [OCSP] are several requests for different CAs at once valid ?

In-line

  _____  

From: Peter Gutmann
Sent: Mon 9/15/2003 8:29 AM
To: [email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked]
Subject: RE: [OCSP] are several requests for different CAs at once valid ?

"Ryan M. Hurst" <[email-masked]> writes:

>Now your just being silly Peter, using pre-produced OCSP responses is no

>worse that using CRLs and it is a cocept explicitly supported by the RFC
for

>the very reasons we implemented it that way.

I agree that technically it's no worse than a CRL.  However, the "O" in
"OCSP"

stands for "Online", not "Offline", which is what the nonceless responder

design is doing to it.  The fact that the name of the protocol is "Online

Certificate Status Protocol" will no doubt lead some poor misguided users to

believe that they're actually getting some sort of live, online check, not

just a query of last week's CRL data.

[rmh] I actualy think its better than CRLs, with the use of OCSP it become
possible to do revocation checking by default on 56k connections for things
like SSL, its also possible to make more frequent updates, etc. As for your
definition your quibling on symmantics, The Online in OCSP does not
necessarily mean the response was dynamically generated, afterall its a
protocol that will only work when its online. Also the fact that responses
are pre-produced does not mean they were issued off of stale data, it simply
means that caching of responses is possible. 
Maybe the RFC title needs to be changed.  Or there could be two variants,
the

"Offline CRL Query Protocol" (OCQP) and OCSP.  The problem at the moment is

that users have no idea what they're getting, presumably all are expecting

OCSP while many are only getting OCQP.  This is at best misleading, and at

worst deceptive if someone's truly relying on it for real, live cert status

info.

[rmh] More sillyness, The response has a thisUpdate, nextUpdate and
ProducedAt; these values are adequare for communicating the freshness
necessary to comminicate publication policy to the user.
Peter.

---

From: Stephen Kent <[email-masked]>
Date: Mon, 15 Sep 2003 18:19:46 -0400

At 14:37 -0700 9/15/03, Deacon, Alex wrote:
>
>I have to agree with Ryan on this one.  Online does not necessarily 
>mean real time.  For example, there are many OCSP responders on the 
>market that get the revocation information from CRL's.  These 
>responders are online, but not real-time.
>
>Anyway, the bottom line is this:  In order to provide OCSP services 
>for very large scale internet pki's (e.g. SSL and code signing CA's) 
>in a *cost effective* way, OCSP responses must be pregenerated, 
>distributed and finally cached through out the network (on clients, 
>proxy's, server's, etc).  
>
>Alex
>

There are two separable issues here.

The first is the source of the revocation status info. OCSP does not 
guarantee that the source of this data is other than CRL-based, as 
noted above. The RFC makes clear that pre-production of responses is 
a legitimate mode of operation.

The second issue is whether the response from the OCSP server is 
current.  Use of nonces in a request-response format is an easy way 
to ensure liveness, but the nonce is an extension, not a part of the 
base protocol. So, obviously, one ought not rely on the presence of a 
nonce in the request or response.

So long as the response contains the producedAt value or the 
thisUpdate value, a client can determine how "current" the response 
is. The RFC requires that thisUpdate appear in pre-generated 
responses, and the producedAt value is a mandatory part of the 
BasicOSCPResponseresponse.

Steve