Hi, Just like in our former email we had a cunfusion with the trust relations between entities shown in figure 1, but after a closer look we now agree with Olle. Best regards,
--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.
What I'm saying is that the CAs may set up a responder that works in Trusted mode -- not that they themselves trust the responder! Here, I was thinking of e.g. the ESNet OCSP service responding to queries for many (all?) of the GridPMA CAs, or a root-level responder answering to all queries in a PKI hierarchy: in both cases, for the responder to be called Authorized, each and every CA in the PMA/PKI would need to issued an OCSP signing certificate! In regards to hierarchies, this is IMO a shortcoming in the RFC, and some OCSP profiles (such as Identrus from the banking world) augments the RFC on this point, to allow for an OCSP responder that is issued an OCSP signing certificate from the root CA to be regarded as Authorized for any certificate in the whole hierarchy. Text should be added in this regard.
* 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.
Good point.
-- 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".
Equivalent text has been added, although the part about hierarchies in the first sentence is not true: see comment above. The last sentence seems like a rather superfluous comment: if you don't trust the CA, you don't trust the responder that is has designated as authoritative.
-- 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".
Equivalent text has been added, although the part about hierarchies in the first sentence is not true: see comment above.
-- ____________________ Jesus Luna Garcia PhD Student. Polytechnic University of Catalonia Barcelona, Spain jluna@ac.upc.edu