Re: Cached OCSP responses vs. single entry CRLs

[David Engberg <dengberg@xxxxxxxxxxxxxx>]

"Cached OCSP" is just OCSP.  The standard defines the binary message 
formats between a client and some server, and includes specific language 
around pre-generation.  Any HTTP server that implements the protocol is 
OCSP.  There is an optional extension (nonce) in the protocol that a 
caching-only server will currently ignore, but this is also in 
compliance with the current spec (i.e. without the proposed MUST language).

There are dozens applications (like Netscape) that natively support 
OCSP, as well as a fair number of appliances (Cisco VPN) and devices 
(RIM Blackberry).  Implementing OCSP typically requires no change in the 
CA or certificate issuance.

In terms of how an implementation produces and distributes pre-generated 
OCSP responses, there are a large number of mechanisms to do this 
(pushing, pulling, rsync, fedex CD-ROMs, etc.).  None of these are 
visible to the relying parties, so I don't think there needs to be any 
mandatory implementation in an RFC.


Carl Wallace wrote:
> The responses regarding lack of client side support are somewhat strange.
> It is not possible that deployed client-side support for partitioned CRLs is
> less than deployed client-side support for the yet-to-be-defined solution
> for cached OCSP.  
>
> On the other side of the transaction, what is the protocol used to populate
> the responders that serve pre-produced responses?  Is this something that
> would need to be standardized too?  There are already standards-based means
> of replicating directories.