Subject: RE: DPD & DPV requirements - Recursion Issues

From: "Covey, Carlin" <[email-masked]>
Date: Wed, 10 Jan 2001 17:10:21 -0800

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:[email-masked]]
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

---

From: Stephen Kent <[email-masked]>
Date: Thu, 11 Jan 2001 15:37:50 -0500

Carlin,

>bit more complex than it might be otherwise.

Right.

>to indicate which practice statement the client is willing

I disagree with part of this. If a DPV server makes use of other DPV 
servers, but returns results that don't indicate such use, then it is 
mostly outside the scope of the protocol, i.e., we could not tell 
from examining the response. It might be stated in a published 
policy, something I would expect for a public server, but not a 
corporate (intranet) server. (Also, this discussion applies just to 
DPV servers, I think; a DPD server returns paths and data for 
ultimate evaluation by the client, so transitive trust is not an 
issue.) It's only when the response to a client include a data 
structure in which some part of the response is itself syntactically 
identified as coming from another DPV server that I think the 
discussion is applicable.

We already assume that a DPV server is making use of various other 
servers, e.g., LDAP servers and OCSP servers. But an LDAP sever is 
not a trusted repository, and a response from an OCSP server is 
clearly marked as such and must be maintained in that fashion to be 
valid. So the transitive trust aspect of simple DPV operation is 
limited to the OCSP responders that it uses.  If the DPV client is 
not PKI-aware, I would not expect it to be able to meaningfully 
influence transitive trust in this way, since such controls require 
an understanding of PKI issues. Only the most basic sort of controls, 
invoked symbolically, might make sense.

>to permit OCSP v1 responses to be embedded in the DPD responses,

As noted above, the DPV and DPD cases are very separate here, and 
only DPV is likely to be a legitimate focus of this discussion. Yes, 
OCSP responses are included, and that introduces the transitive trust 
issue, but unless OCSP allows for recursion itself, I think we have 
an inherent limit in this case, i.e., it's not recursive, just 
1-level delegation. Also, if one has a flag to say whether any OCSP 
responses are considered legitimate, then this provides a level of 
control that is simple to understand and exactly matches the 
delegation.

Steve