RE: DPD & DPV requirements - Recursion Issues

["Covey, Carlin" <ccovey@xxxxxxxxxx>]

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