RE: DPD & DPV requirements - Recursion Issues

[Peter Sylvester <Peter.Sylvester@xxxxxxxxxx>]

> 
> Frank and Peter,
> 
> I'd be happy for someone to define a set of terms for use in this
> context, if it would benefit the discussion.
Yes.

> 
> The "transitive trust" issue that was referred to earlier arises in
> the context of "relaying" DPV status.  The client asks server 1 to 
> validate the status of a certificate, and server 1 "relays" some or
> all of the validation process to server 2.  When the response comes
> back from server 2, server 1 then prepares a response to the client
> based wholly or in part on the information obtained from server 2.

Where do you have "transitive trust"? Client trusts server 1, and that's
all. Client may inspect server 1 response in order to inform its "client"
that server 1 came to whatever conclusion because he has reveived
an answer from 2, but that doen not mean that client has to trust server 2.

> 
> When I originally used the term "recursion" I had in mind a recursive
> data structure, i.e. a DPD response that contains another DPD
> response that might in turn contain another DPD response.  This is one
> method for returning the "relayed" status information to the client. 


> This particular method raises the syntactic complexity issue that
> was mentioned in a previous email.  This syntactic complexity is avoided
> if server 1 extracts information from server 2's response and repackages 
> it into a nonrecursive data structure that it then sends to the client.

I have in mind that the server 1 always creates a new answer. This answer
is authoritive. As an additional information, OCSP responses, other servers
responses are added. A client does not need to look at them in order to
do this business. 

> As I mentioned in an earlier email, one advantage of the recursive data
> structure is that it allows the optional timestamp on the embedded DPD
> responses to be retained.

Whatever is contained in a response, it is left untouched. 

regards
peter