Mike Helm wrote:
Olle Mulmo writes:
I would say that your responder got confused up by the proxy certs. Possbily also that that it is one of the responders that cannot handle multi-certificate requests (array count > 1).
I think (guess) it is more likely the latter, but don't know. I will try to rig up some kind of test that can see what our demo OCSP responder can do with a couple chained CA's and an EE cert (probably as close as ESnet can get rite now).
I think what we should do is request developers of client and OCSP server code support properly parsed multiple cert OCSP requests but recommend against using them. This sounds ridiculous but until we fully understand how the commercial servers work...
About this point we would like to tell you about our practical experience obtained with the implementation of OCSP (CertiVeR API) into GT4: -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). -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. -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. The process described above could be implemented with any RFC2560 compliant OCSP Provider and will consider a Proxy Certificate as Revoked if any certificate from the EEC to the correspondent CA has been revoked. However further support for fine-grain Proxy Certificates revocation could be developed just as we have done with CertiVeR: -When a subject wants to delete a Proxy Certificate before ending its Validity Period (i.e. executing a grid-proxy-destroy) then it notifies the revocation of such certificate to CertiVeR. -CertiVeR authorizes the Revocation Request (Proxy's Unique Name feature eases such AuthZ) and registers corresponding revocation data (issuerKeyHash, issuerDNHash and Serial) into its database (for a description of CertiVeR revocation model take a look at www.certiver.com). -From now on CertiVeR will able to respond with a final "Revoked" status for such Proxy Certificate, thus allowing a fine-grain revocation.. Best regards, -- ____________________ Jesus Luna Garcia PhD Student. Polytechnic University of Catalonia Barcelona, Spain jluna@ac.upc.edu