[caops-wg] OCSP section 7

[Olle Mulmo <mulmo@xxxxxxxxxx>]

> --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.