Subject: RE: Cached OCSP responses vs. single entry CRLs

From: "Deacon, Alex" <[email-masked]>
Date: Fri, 5 Dec 2003 16:04:46 -0800

We looked into this.  The problem is that client support for "crl
partitioning" (in this case a partition by individual serial number) is just
about non-existant. 

Alex

> -----Original Message-----
> From: Carl Wallace [mailto:[email-masked]] 
> Sent: Friday, December 05, 2003 1:09 PM
> To: [email-masked]
> Subject: Cached OCSP responses vs. single entry CRLs
> 
> 
> 
> Why use OCSP to convey pre-produced revocation information in 
> the way that's being discussed?  Why not use single entry 
> CRLs?  The functionality is similar and they could be 
> propagated using existing technology (e.g. directories, 3280 
> compliant path processing clients, etc.).
>

---

From: "Carl Wallace" <[email-masked]>
Date: Mon, 8 Dec 2003 08:39:22 -0500

Response to following two comments below...

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Deacon, Alex
> Sent: Friday, December 05, 2003 7:05 PM
> Subject: RE: Cached OCSP responses vs. single entry CRLs
> 
> We looked into this.  The problem is that client support for 
> "crl partitioning" (in this case a partition by individual 
> serial number) is just about non-existant. 
> 
> Alex
> 

> From: Ryan M. Hurst [mailto:[email-masked]] 
> Sent: Friday, December 05, 2003 6:30 PM
> Subject: RE: Cached OCSP responses vs. single entry CRLs
> 
> Carl there are a number of reasons, one of the most 
> significant being backwards compatibility; many existing 
> client implementations do not support partitioned CRLs and 
> there is not way to tell from a CDP if the data on the other 
> end represents a partitioned CRL or a full one.
> 
> Additionally there are commercial OCSP responders out there 
> that support this concept, yet very few CAs support the use 
> of portioned CRLs to that granularity.
> 
> Ryan

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.

---

From: David Engberg <[email-masked]>
Date: Mon, 08 Dec 2003 09:55:36 -0500

"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.

---

From: "Carl Wallace" <[email-masked]>
Date: Mon, 8 Dec 2003 10:28:55 -0500

> From: David Engberg [mailto:[email-masked]] 
> Subject: Re: Cached OCSP responses vs. single entry CRLs
> 
> In terms of how an implementation produces and distributes 
> pre-generated OCSP responses, there are a large number of mechanisms to do
this 
> visible to the relying parties, so I don't think there needs 
> to be any mandatory implementation in an RFC.
> 

That it is not visible to relying parties does not necessarily remove a need
for standardization.  It's easy to see where non-standardization of the
means of replication would lock folks into a particular vendor's solution.
For what it's worth, I'm not lobbying for additional standardization efforts
in that area.  The point is that there exist today ample standards to deploy
a solution that is more or less functionally equivalent to "cached OCSP" or
"nonce not supported OCSP".