[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Cached OCSP responses vs. single entry CRLs



Title: RE: Cached OCSP responses vs. single entry CRLs
Carl - These are just a few of the reasons, as for your question consider the scenario of a issuer having to support mixed version/heterogeneous environments.
 
Although more recent Microsoft clients support partitioned CRLs, that does not mean the ones before this concept existed do, what about clients based on open source implementations, or ones running on other operating systems that do not have support for this concept?
 
TTPs still need to provide their subscribers and their relying parties with revocation information without having to require subscribers to have different profiled certificates for communication with different constituents. Today if a CDP pointed to a partitioned CRL these clients lacking support for this concept would not be able to validate the CDP.
 
The use of OCSP gets around this issue, as long as we do not introduce any breaking changes into the protocol (and don't forget the RFC did allow for the pre-production concept explicitly).
 
Beyond the deployability concepts above, OCSP has a number of other benefits as well that make it a very natural fit (400 byte responses for example); also considering there are vendors with products that deal with these concepts available today OCSP really is the natural solution. 
 
Ryan


From: Carl Wallace [mailto:cwallace@xxxxxxxxxxxx]
Sent: Mon 12/8/2003 5:39 AM
To: 'Deacon, Alex'; Ryan M. Hurst; ietf-pkix@xxxxxxx
Subject: RE: Cached OCSP responses vs. single entry CRLs

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.