[caops-wg] OCSP section 7

[Jesus Luna]

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 at ac.upc.edu