OCSP APIs for MyProxy and GT4 - Requirements document?
Dear all, It's been a while since we last discussed about this document and with the upcoming birth of the OGSA-AuthN WG we would like to ask you if the OCSP draft should be put into "hibernation" until the new charter is ready, or if we should try to give it a push still from the CAOPS-WG. We have been aware of the adoption of an OCSP client into a new MyProxy release, and on the other hand OGRO is about to be submitted for evaluation as a patch to Globus' Java core. Maybe it's a good time to push the document again, isn't it? Best regards, Jesus & Oscar
jluna@ac.upc.edu writes:
We have been aware of the adoption of an OCSP client into a new MyProxy release, and on the other hand OGRO is about to be submitted for evaluation as a patch to Globus' Java core. Maybe it's a good time to push the document again, isn't it?
yes. what's the general capability of the myproxy ocsp client, or its intended application &c? thanks, ==mwh
Mike Helm <helm@fionn.es.net> wrote:
jluna@ac.upc.edu writes:
We have been aware of the adoption of an OCSP client into a new MyProxy release, and on the other hand OGRO is about to be submitted for evaluation as a patch to Globus' Java core. Maybe it's a good time to push the document again, isn't it?
yes.
I agree. I've found the OCSP Requirements for Grids document useful for my work adding OCSP support to MyProxy (http://bugzilla.ncsa.uiuc.edu/show_bug.cgi?id=281) and the GT C GSI libraries (http://bugzilla.globus.org/bugzilla/show_bug.cgi?id=4788), and I'd like to see it published as a GGF draft. One comment I'll make is the MyProxy example in the appendix is odd considering the recommendation elsewhere in the document not to include proxy certificates in OCSP requests.
what's the general capability of the myproxy ocsp client, or its intended application &c? thanks, ==mwh
In an upcoming MyProxy release, it will be possible to configure the myproxy-server to check certificate status via OCSP for stored credentials before delegating a proxy certificate from those credentials. -Jim
Jim Basney writes:
One comment I'll make is the MyProxy example in the appendix is odd considering the recommendation elsewhere in the document not to include proxy certificates in OCSP requests.
Amen!
what's the general capability of the myproxy ocsp client, or its intended application &c? thanks, ==mwh
In an upcoming MyProxy release, it will be possible to configure the myproxy-server to check certificate status via OCSP for stored credentials before delegating a proxy certificate from those credentials.
Do you have any UI for altering the OCSP-reported status of certs in the myproxy server's store? If so, how does this work, or how do you think it should work in general? I think this is appropriate to understand (and relevant to this document), because if we should want to generalize this idea to other kinds of certificate management, we should also want to provide the same kinds of interfaces for cert revocation everywhere. Thanks, ==mwh
Mike Helm <helm@fionn.es.net> wrote:
Jim Basney writes:
One comment I'll make is the MyProxy example in the appendix is odd considering the recommendation elsewhere in the document not to include proxy certificates in OCSP requests.
Amen!
what's the general capability of the myproxy ocsp client, or its intended application &c? thanks, ==mwh
In an upcoming MyProxy release, it will be possible to configure the myproxy-server to check certificate status via OCSP for stored credentials before delegating a proxy certificate from those credentials.
Do you have any UI for altering the OCSP-reported status of certs in the myproxy server's store? If so, how does this work, or how do you think it should work in general? I think this is appropriate to understand (and relevant to this document), because if we should want to generalize this idea to other kinds of certificate management, we should also want to provide the same kinds of interfaces for cert revocation everywhere.
Note that I wrote that MyProxy will *check* certificate status via OCSP, not *report* certificate status via OCSP. The myproxy-server will query an external OCSP service, not provide an OCSP service itself. The management interface to the OCSP service is out of scope for MyProxy. -Jim
Jim Basney writes:
what's the general capability of the myproxy ocsp client, or its intended application &c? thanks, ==mwh
In an upcoming MyProxy release, it will be possible to configure the myproxy-server to check certificate status via OCSP for stored credentials before delegating a proxy certificate from those credentials.
How does it, or how do you see it choosing, between a configured OCSP responder (a default responder?), AIA extensions in EE certs, or local CRL files? Thanks, ==mwh
Mike Helm <helm@fionn.es.net> wrote:
Jim Basney writes:
what's the general capability of the myproxy ocsp client, or its intended application &c? thanks, ==mwh
In an upcoming MyProxy release, it will be possible to configure the myproxy-server to check certificate status via OCSP for stored credentials before delegating a proxy certificate from those credentials.
How does it, or how do you see it choosing, between a configured OCSP responder (a default responder?), AIA extensions in EE certs, or local CRL files?
The "OCSP Requirements for Grids" document says: relying parties MUST be capable of handling both CRLs and OCSP, and it MUST be a configurable option which source of revocation to prefer and which to use as a backup, on a per-issuer basis. and: Local configuration MUST have precedence over any service locator information located in the certificate's AIA extension. A default responder for all other issuers SHOULD be configurable as well. I find the configuration requirements in the document to be quite complex, and I suspect MyProxy will not meet them fully any time soon. MyProxy will implement the following to start: - Always check CRLs if present. - Allow configuration of a trusted local OCSP responder. - Allow configuration of whether OCSP responders should be located via AIA extensions. - Allow configuration of whether the trusted local responder or AIA responder should take precedence. -Jim
Jim Basney writes:
I find the configuration requirements in the document to be quite complex, and I suspect MyProxy will not meet them fully any time soon.
If you have some other ones, please post them. As a developer of a client, what would you prefer in this case - acquiring revocation information? Thanks, ==mwh
Mike Helm <helm@fionn.es.net> wrote:
Jim Basney writes:
I find the configuration requirements in the document to be quite complex, and I suspect MyProxy will not meet them fully any time soon.
If you have some other ones, please post them.
Do I have other configuration requirements? My only requirement is for something that is simple to implement, support, and configure. Otherwise, I find the requirements in the document to be already quite exhaustive.
As a developer of a client, what would you prefer in this case - acquiring revocation information?
Sorry, I don't understand the question. I wrote in my last message what I plan to implement in MyProxy for now. For example, I won't be adding per-issuer configuration as required in the document, but I will be supporting both CRLs and OCSP. -Jim
Jim Basney writes:
As a developer of a client, what would you prefer in this case - acquiring revocation information?
Sorry, I don't understand the question. I wrote in my last message what
Well, if you decided to support OCSP and this document didn't exist, what would have have done?
Mike Helm <helm@fionn.es.net> wrote:
Jim Basney writes:
As a developer of a client, what would you prefer in this case - acquiring revocation information?
Sorry, I don't understand the question. I wrote in my last message what
Well, if you decided to support OCSP and this document didn't exist, what would have have done?
For configuration of what responders to contact? I don't think I'd have done anything different. For other things? I probably would have used nonces, if I didn't read in the document that they shouldn't be used. I probably would have packaged multiple certificates in one request, if I didn't read in the document that that's rarely done. As I wrote before, I found the document to be useful. I think it's a good document. -Jim
Does your product make any provision for caching responses?
Jim Basney writes:
Does your product make any provision for caching No. Are you (or anyone else) aware of any open source OpenSSL-based OCSP clients that do?
I'm not; I thought probably the practical way to do this would turn out to be localhost:OCSP_local_url
Mike Helm wrote:
Does your product make any provision for caching responses? -- caops-wg mailing list caops-wg@ogf.org http://www.ogf.org/mailman/listinfo/caops-wg
Hello Mike and Jim, Sorry for the delayed responses :) First of all I think that Jim's implementation is of great value and a good step towards finally supporting OCSP into Grids. In the last months we (at UPC) have been planning to port OGRO to C language, unfortunately we don't have enough resources (aka volunteers) to do the job and instead both Oscar Manso (Grid-OCSP server) and me (Grid-OCSO client) have tried to evolve the OGRO middleware thanks to our research on Grid-validation and comments from the users community. We expect to contact Frank Siebenlist in the following days with an updated/debugged OGRO version, to see if it's possible to included it as a patch to the GT's Java Core. So from my point of view thanks to Jim's effort we may be able to: i) Finish for good (that's the correct English phrase?) the OCSP Reqs Document. As far as I remember, the version posted at the CAOPS' site was in need of a readability checking and now we may need to update appendixes A.3 (MyProxy example) and B (client conf examples) according to Jim's experience and comments. ii) If possible I'd like to use Jim's source code to begin working towards a "OGRO-C" which may be configured in a way similar to the Java-based version. Potential users would be happy to configure its clients in an analogous way and now we are closer to that if you believe that OGRO's config file may be useful. I'd try to work towards this goal in the short-term ;) Finally about Responses' caching: in OGRO we implemented this feature as an add-on to the JCE Provider being used (currently Bouncy Castle/IAIK), by keeping an in-memory structure that's constantly being purged of non-definitive cert statuses. As I told you this may added into the OGRO-C port thanks to Jim's client. In any case you might be interested into this one: “OCSP for Grids: Comparing Prevalidation versus Caching”. Luna, Jesús. Manso, Oscar. Manel, Medina. Accepted for the 7th IEEE/ACM International Conference on Grid Computing, Barcelona, September 2006. http://www.grid2006.org/ I don't know if it can be posted here, but if you're interested then for research purposes you can contact me directly. :) Best regards, -- <><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><> o o o Jesus Luna Garcia | Polytechnic University of Catalonia o o o PhD Student | Department of Computer Architecture o o o phone: +34 93 401 7187 | Campus Nord. www.ac.upc.es U P C fax: +34 93 401 7055 | C/Jordi Girona 1-3, Modul D6-116 E-mail: jluna@ac.upc.es | Barcelona 08034 SPAIN <><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>
Jesus Luna writes:
Finally about Responses' caching: in OGRO we implemented this feature as an add-on to the JCE Provider being used (currently Bouncy Castle/IAIK),
This is very useful, because I think that a successful caching mechanism is also a large part of what would be needed for a local responder that provides blacklisting or proxy cert revocation capability. Thanks, ==mwh
Hi, So, after the emails we've exchanged: shall we do some additional work on the OCSP document? I've just sent an email to Frank about the newest version of OGRO so it may be possible to continue working on its integration into the GT. In the meantime I'll try to take a look at Jim's implementation to measure the effort to re-use it for an OGRO-C port. I'd try to do it in the mid-term as now we're trying to implement a Grid-PKI evaluation technique into OGRO itself :) Best regards, Jesus Mensaje citado por Mike Helm <helm@fionn.es.net>:
Jesus Luna writes:
Finally about Responses' caching: in OGRO we implemented this feature as an add-on to the JCE Provider being used (currently Bouncy Castle/IAIK),
This is very useful, because I think that a successful caching mechanism is also a large part of what would be needed for a local responder that provides blacklisting or proxy cert revocation capability.
Thanks, ==mwh
participants (4)
-
Jesus Luna -
Jim Basney -
jluna＠ac.upc.edu
-
Mike Helm