RE: DPD & DPV requirements - Recursion Issues

[Frank Balluffi <frankb@xxxxxxxxxxxx>]

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.

Frank

> -----Original Message-----
> From: Covey, Carlin [mailto:ccovey@xxxxxxxxxx]
> Sent: Wednesday, January 10, 2001 8:10 PM
> To: PKIX-List
> Subject: RE: DPD & DPV requirements - Recursion Issues
> 
> 
> Steve,
> 
> I'm sorry that this isn't much of an analysis, but I think
> that any such analysis should clearly separate the issues.
> Here are three issues that I can think of:
> 
> 1) One issue concerns the syntactic complexity of the protocol.
> If the protocol permits a DPV/DPD response to include embedded 
> DPD/DPD responses from other servers, then the syntax will be a
> bit more complex than it might be otherwise.
> 
> 2) A second issue concerns transitive trust.  This is an issue
> even if embedded responses aren't permitted in the protocol.
> A DPV/DPD server could contact another server and repackage
> the response that it receives.  This issue might be addressed
> by providing hooks in the protocol to limit the extent of this
> transitive trust.  On the other hand, the issue might be 
> addressed by DPV/DPD server practice statements. "This is what
> I might do, trust me or not."  Or the issue might be addressed
> by a combination of the two by using policy OIDs in the request
> to indicate which practice statement the client is willing
> to tolerate.
> 
> 3) A third issue is whether the benefits of recursion outweigh the
> difficulties presented by the first two issues.  The authors of
> the SCVP and OCSP-DPV proposals, and the author of the proposed
> DPV/DPD requirements (someone well known to you, Steve) all chose 
> to permit OCSP v1 responses to be embedded in the DPD responses, 
> despite issues 1 and 2.
> 
> Regards,  Carlin
> 
> ----------------------------
> - Carlin Covey
>   Cylink Corp.
> 
> 
> 
> -----Original Message-----
> From: Stephen Kent [mailto:kent@xxxxxxx]
> Sent: Wednesday, January 10, 2001 3:10 PM
> To: Slone, Skip
> Cc: PKIX-List
> Subject: RE: DPD & DPV requirements
> 
> 
> Skip,
> 
> If we do agree to support DPV server recursion, then the suggested 
> changes are appropriate ones to consider.
> 
> First, though, on what basis would you propose that a client 
> enable/disable recursion or set a depth limit? Since a client is 
> completely dependent on a DPV server to answer a query, and has no 
> local means of validating any supporting data sent along with the 
> answer, what does recursion say about the trust that the client 
> places in the server? If one believes that trust is transitive, 
> recursion may well be fine, and a simple numerical limit on depth of 
> recursion would not seem to be a good way to express limits on the 
> transitivity (e.g., one bad choice of a DPV server for reliance is 
> enough to kill you). If you don't think trust is transitive, then 
> recursion is inappropriate, unless you operate in a closed 
> environment where the recursion is among servers operated by the same 
> org and is really just an internal decision on how to implement the 
> server.
> 
> Perhaps this is one reason why I am not yet comfortable with adding 
> recursion to servers. I'd like to see some analysis of why it makes 
> sense, whether it makes sense for both DPD and DPV, etc.
> 
> Steve
>