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

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.