[caops-wg] OCSP - proxy certs

Mike Helm helm at fionn.es.net
Fri Jun 3 19:54:38 CDT 2005


Jesus Luna writes:
[we were discussing problems dealing with chains 
of proxy certs->EE cert, and how to manage OCSP requests based on them]

> -First of all RFC2560 defines a request structure containing a 
> "requestList" element, in other words any OCSP Provider compliant with 
> such recommendation should provide this support.

> -Our OCSP client library parses each certificate from the Proxy´s chain 
> as "Request" elements of such "requestList", which means that it is 
> client's responsability to obtain such chain (which in fact is provided 
> by GT4 APIs ie when initializing a Proxy).

What is the status of this client library?  Is it freely available to
developers?

Am I interpreting this correctly:  "The client library will parse
a chain of proxy certs in the correct RFC 2560 form (requestList &c)
and create a RFC 2560 conforming OCSP query"?

> -When the OCSP Responder parses the "requestList" it will obtain the 
> "CertStatus" for each contained certificate as follows: i) From the Root 
> to the EEC it will respond with any of the good, revoked or unknown 
> statuses,  ii) for any ProxyCertificate contained it will never respond 
> a "good" status just because it would be very expensive to register 
> every Proxy Certificate into the CA. However any standard Responder may 
> generate an "unknown" status.

We need to think about this, in terms of supporting proxy
certs.  Should we expect clients to distinguish proxy certs
from EE or issuer certs?  (I would answer "No", but they could.)
We might have a lot of "unknown" status returns - the client
will react to this how?  (Possibly not well, given the 
recommended default.)

Can we train trusted responders to return  "Good" unless
the proxy is revoked?  Would this be a good thing to do?

> -When the client library receives the OCSP Response and parses each of 
> the "SingleResponse" structures it will conclude that a Proxy 
> Certificate is revoked if its "CertStatus" has such value, otherwise it 
> will be considered as Valid.

Why?  (It sounds reasonable, but what about previous discussion of
exhausted revocation information.)  We need either to clear this up
or clear up my misunderstanding :^)





More information about the caops-wg mailing list