RE: DPD & DPV requirements - Recursion Issues

[Frank Balluffi <frankb@xxxxxxxxxxxx>]

Carlin Covey wrote:

> 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 agree. I like the following:

client
  |
  | (DPD/DPV)
  |
server 1
  |
  | (supporting protocol (e.g., OCSP))
  |
server 2
  |
  | (supporting protocol)
  |
server 3

or

      client
        |
        | (DPD/DPV)
        |
      server 1
  |             |
  |             |
  |             |
server 2     server 3

more than:

client
  |
  | (DPD/DPV)
  |
server 1
  |
  | (DPD/DPV)
  |
server 2

Frank

> -----Original Message-----
> From: Covey, Carlin [mailto:ccovey@xxxxxxxxxx]
> Sent: Thursday, January 11, 2001 11:18 AM
> To: ietf-pkix@xxxxxxx
> Subject: RE: DPD & DPV requirements - Recursion Issues
> 
> 
> 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.
> 
> 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.
> 
> 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.
> 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.
> 
> Regards,
> 
> Carlin
> 
> ------------------------------
> 
> - Carlin Covey
>   Cylink Corp.
> 
> 
> 
> -----Original Message-----
> From: Peter Sylvester [mailto:Peter.Sylvester@xxxxxxxxxx]
> Sent: Thursday, January 11, 2001 8:59 AM
> To: ccovey@xxxxxxxxxx; ietf-pkix@xxxxxxx; frankb@xxxxxxxxxxxx
> Subject: RE: DPD & DPV requirements - Recursion Issues
> 
> 
> > Content-Length: 3514
> > 
> > Wouldn't a DPD/DPV server solely carry out the task of 
> discovering and
> > validating paths, and possibly use other protocols (e.g., 
> LPAP, OCSP,
> etc.),
> > which might be recursive, to assist in this process? So 
> unless sub-DPD/DPV
> > servers take part in path discovery or validation I would 
> not describe
> > DPD/DPV as recursive.
> > 
> 
> 'Recursive' lay not be the right word, but you can have relaying
> or delegation or proxying. 
> 
> In the above, replace 'OCSP' by DPV': - instaed of asking
> for the revocation status, you ask for the validity status.
> This isn't that different, and even in OCSP you already have
> relaying.
>