RE: Cached OCSP responses vs. single entry CRLs

["Santosh Chokhani" <chokhani@xxxxxxxxxxxx>]

Jean-Marc:

To match the DP in the IDP in CRL, you need to match the DP in CDP in the
certificate.  cRLIssuer field needs to come in to play only if there is an
indirect CRL issuer.

If the client does not know how to process a critical extension (which IDP
is) and still uses a PKI object (certificate or CRL), I am sure lots of
other things can go wrong.  Just look at some of the other vulnerabilities
identified and corrected over the last few months.

As to lack of client side support, when did that became a basis for putting
out yet another standard and requiring yet another client side plug-in.  I
am sure adding IDP processing to certificate and CRL processing is lot
easier than defining and adding an OCSP client.

-----Original Message-----
From: owner-ietf-pkix@xxxxxxxxxxxx [mailto:owner-ietf-pkix@xxxxxxxxxxxx] On
Behalf Of Jean-Marc Desperrier
Sent: Tuesday, December 09, 2003 3:00 PM
To: ietf-pkix@xxxxxxx
Subject: Re: Cached OCSP responses vs. single entry CRLs



From: Carl Wallace

>     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.
>
Santosh Chokhani wrote:

> The client concern does not seem to cut the mustard since Carl's 
> argument is that we do not seem to have a standard for nonceless 
> client, let alone capability.  For the partitioned CRL, we have 
> well-defined standard.
>  
> As to the response size, I am sure that a partitioned CRL (one CRL for 
> each certificate) will be less than 400 bytes you cited. I think 
> partitioning CRL for individual certificate has plusses in terms of 
> standard and removing the need for client.  It also has directory 
> related plusses in terms of replication.
>  
> I think its minuses are in terms of CA's ability to support it (or 
> requiring delegated CRL issuer, i.e., Indirect CRL Issuer Model) and 
> may be addition and management of entries under the CA branch for the 
> CRL partitions.

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.