RE: Cached OCSP responses vs. single entry CRLs

["Carl Wallace" <cwallace@xxxxxxxxxxxx>]

Response to following two comments below...

> From: owner-ietf-pkix@xxxxxxxxxxxx 
> [mailto:owner-ietf-pkix@xxxxxxxxxxxx] 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:rmh@xxxxxxxxxxxxxxxxxxxxx] 
> 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.