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 :^)