[caops-wg] OCSP requirements - final(?) version uploaded

[Jesus Luna]

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 at certiver.com

Jesus Luna
Universitat Politecnica de Catalunya
Jordi Girona 1-3, D6 116. Barcelona
Spain
email: jluna at 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 at ac.upc.edu