*Section 5.5 talks about support for proxy certs. I obviously don't think it is out of scope - we MUST talk about it - but it is indisputable we don't know how to deal with them. But punting completely is leaving a lot of the potential value added of Grid OCSP out.
You are right. Your suggested text (cut) will be added.
We might also want to tell developers and OCSP client configurers OCSP queries on proxy certs are NOT RECOMMENDED and should be avoided, except by prior agreement and consultation with specially configured OCSP responders that can deal with them.
Yep.
*Section 5.3 The sources must be properly protected against malice use.... Suggest [maybe it's overload]
The text below sounds fine to me -- with a reservation for replacing some of the wording with MUSTs.
The OCSP responder database must be protected properly. In most cases the database will be updated automatically, and adequate change control and logging must be used to ensure data is obtained and loaded from a trusted source in a timely fashion. Signatures on CRLs must be checked and CRLs must be refreshed in a timely fashion. OCSP responders must ensure that proper change control and access controls are in place to prevent unauthorized addition or removal of certificate status information from the database. This is particularly important to any OCSP service providing experimental support for proxy certificate verification (see section 5.5).
...
Customer expressed interest in dealing with proxy certs. The situation seems to be that in practice a chain of certs is available, from the EE to the last proxy cert. Our experimental responder didn't deal with that well, apparentlhy peeling off the first one and skipping any others (first one being the last proxy cert).
The standard reads (to me) as ambiguous about this, which surprised me, because I expected the above behavior: (RFC 2560 page 2)
The response for each of the certificates in a request consists of
-- target certificate identifier -- certificate status value -- response validity interval -- optional extensions
Is this a bug in the spec, or the implementation? What is the OCSP server "art" on this since this spec came out? There is a remark about this somewhere in section 3 - it seems to be sort of out of place.
I don't follow. There's definitely not a bug in the spec: a response has issuer producedAt timestamp array of certificate status responses nonce if provided, and other extensions signature where the array of certificate status responses contain the things you list above, for each certificate that status was queried for: identifier of the cert (hash of issuer name + serial#), it's status (good/revoked/unkown), how long this status is valid for (e.g., the thisUpdate/nextUpdate fields of the CRL), and possible extensions (e.g. revocation reason codes, the location of the CRL that was consulted, ...). 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). /Olle
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...
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
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 :^)
Mike Helm wrote:
What is the status of this client library? Is it freely available to developers?
We are in touch with Frank Siebenlist (Lead Security Architech from Globus) to integrate our OCSP client library (the Java version is only available at this time) into GT4.
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"?
Yes, that is correct.
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.)
The client is the only one that can identify Proxy Certificates (in fact it is pretty easy to do with the CoG Java implementation) therefore releasing the OCSP server from such "customization".
We might have a lot of "unknown" status returns - the client will react to this how? (Possibly not well, given the recommended default.)
Exactly, that's why we recommended in our original email two possibles approaches to this problem: -From the client side: 1-If no "Revoked" status was received from the OCSP for the whole requestList then the Proxy Certificate is valid. This behaviour considers any RFC2560 compliant OCSP Server. -From the OCSP Server side: 1-A standard OCSP Server that does not support Proxy Certificates Revocation should always reply an "Unknown" status for such certificates. 2-An OCSP Server that does support Proxy Certificates Revocation (like CertiVeR where its database stores Proxy Certificates that have been revoked) will reply "Unknown" only if the Proxy Certificate has not been revoked.
Can we train trusted responders to return "Good" unless the proxy is revoked? Would this be a good thing to do? 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 :^)
It is not advisable because given an X509 Certificate, the OCSP Server does not have a secure mechanism to identify a Proxy Certificate. Best regards, -- ____________________ Jesus Luna Garcia PhD Student. Polytechnic University of Catalonia Barcelona, Spain jluna@ac.upc.edu
Jesus Luna writes:
The client is the only one that can identify Proxy Certificates (in fact it is pretty easy to do with the CoG Java implementation) therefore releasing the OCSP server from such "customization".
How does this client do this? One of the motivations for doing OCSP is to lighten the cert checking burden on the client (to 1 ocsp status check call). So I think it would be good if we understood this issue better.... Thanks, ==mwh
participants (3)
-
Jesus Luna -
Mike Helm -
Olle Mulmo