Hi, After reading the document I've only a few comments: * The header has something like "Jesus Luna, UAB". Could you please change it to "Jesus Luna, UPC" as I'm at the Universitat Politecnica de Catalunya :) * BTW Authors affiliation (section 10) for Oscar and myself are: Oscar Manso CertiVeR Diputacion 238 1o 4a. Barcelona Spain email: o.manso@certiver.com Jesus Luna Universitat Politecnica de Catalunya Jordi Girona 1-3, D6 116. Barcelona Spain email: jluna@ac.upc.edu * In section 2 (former section 3) the following text was removed: "Grid’s Virtual Organizations may contain more than one CA, so establishment of OCSP Authorized Responders between them is essential to provide an interoperable service." When we proposed such change we were thinking in the importance of highlighting the co-existence of multiples CAs into the same VO as a practical challenge for Grid OCSP. What do you think? * We noted that references to "Global Redirector Mode" (former section 6.5) were integrated into section 5.4 (current document) as "central redirector". That was an appropiate change as it defines very well the idea behind this concept, good! :) * Page 7, section 5.5: the paragraph suggesting the use of Delta CRLs to obtain Proxy Certificate´s status has been deleted ("Another option refers to using OCSP in a Push Operation Mode as mentioned in section 6.3, where relying parties SHOULD obtain revocation information through its OCSP service provider as soon as it is updated by the corresponding CA through Delta-CRLs"). Only as a way to let the reader know about this possibility, don't you think that it is worth to keep? * In section "7. OCSP Service Architecture" we have a couple of suggestions: --In the last paragraph on page 9 we propose to clarify the text "...incoming OCSP request in turn copied by the OCSP client from the subscriber certificate that is currently being validated." changing it with the following "...incoming OCSP request specified by the client according to the AIA extension in the certificate that is currently being validated". --In the second paragraph on page 10 the text "...may join efforts and set up a shared Trusted responder that serves requests on behalf on all of the CAs", from our point of view if a set of CAs will trust in a Responder then it becomes an Authorized Responder. That is because by definition the CA does not *trust* in a Trusted Responder (in fact is the User who *trusts* in such Trusted Responder) . Because is the CA which *trusts* in the Authorized Responder we propose to modify the original text with: "...may join efforts and set up a shared Authorized responder that serves requests on behalf on all of the CAs". The "Note" right after the original text should be kept as it defines precisely the *trust* relation between PMAs and OCSP responders. *We have been analyzing the new diagram in figure 1 and we find that we would need to clarify the trust relationships among the different components that are presented. For this reason, we suggest that in section 7 we could add a couple of lines to definitions 7.1 and 7.2 referring to "trust relationships" between User-Trusted Responder-Authorized Responder-CA, which may help to justify the architecture (figure 1): -- At then end of definition 7.1: "The CA trusts in the Authorized Responder as a source of status information for the certificates of its own hierarchy . On the other hand, if the Client does not trust such hierarchy then it will not trust in such Authorized Responder". -- At the end of denifition 7.2: "The User trusts in the Trusted Responder as a source of status information for the CAs hierarchies which it has configured. However these CAs will not implicetly trust in such Trusted Responder". If these two points require further discussion, we suggest to ommit them from the document and discuss them during the GGF14 meeting. Best regards and we'll be looking forward for your comments, Oscar & Jesus Olle Mulmo wrote:
All,
I cleaned up the document and resolved some of the outstanding issues. Tracking was too hard to keep around (too many changes) so I removed those.
Note that document submission for GGF14 is tomorrow. I would request that the members of this list read through the document NOW (yes, prior to the meeting), and bring up any comments on the document on this list, ideally so that we can go to GGF14 with the document in WG last call.
The document can be obtained at
https://forge.gridforum.org/projects/caops-wg/document/ OCSP_requirements_for_Grids/en/1
A PDF rendering is attached for your convenience.
/Olle
-- ____________________ Jesus Luna Garcia PhD Student. Polytechnic University of Catalonia Barcelona, Spain jluna@ac.upc.edu