RE: Cached OCSP responses vs. single entry CRLs

["Carl Wallace" <cwallace@xxxxxxxxxxxx>]

> From: owner-ietf-pkix@xxxxxxxxxxxx 
> [mailto:owner-ietf-pkix@xxxxxxxxxxxx] On Behalf Of Jean-Marc 
> Desperrier
> Subject: Re: Cached OCSP responses vs. single entry CRLs
> 
> You are missing a major minus of partitioning CRL that 
> many/most client 
> don't support partitioned CRL, but worst do not properly 
> recognize the 
> cRLIssuer part of the CRLDP, and will not be able to match it 
> to the IDP 
> inside the crl, so they can be pushed to trust a partionned CRL for a 
> cert it doesn't apply too.
> *That* is the concern for lack of client side support. In the current 
> state of things, partionned CRL is very probably a security 
> hazard for 
> many clients.
> 
> Meanwhile using cached OCSP without any of the addition 
> discussed here 
> is not a problem as long as the client is configured not to 
> require a nonce. The proposed OCSP change is an optimization, 
> not absolutly required.
> 

As you pointed out in a subsequent post, a client that doesn't support
partitioned CRLs should choke on a critical IDP and (possibly) be unable to
determine the revocation status of the certificate in question.  This is
similar to an OCSP client that uses nonces when interacting with a caching
OCSP responder.  Faulty implementations are a different matter.