Subject: RE: DPD & DPV requirements - Recursion Issues

From: Frank Balluffi <[email-masked]>
Date: Thu, 11 Jan 2001 07:10:30 -0800

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:[email-masked]]
> 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:[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 16:35:05 -0500

Frank,

>servers take part in path discovery or validation I would not describe

I think we're mostly in agreement. We expect an DPV or DPD server to 
make use of other servers, e.g., LDAP and OCSP. If an LDAP server 
makes a recursive call, the results can (should?) still be 
"flattened" before returning to the user and have no security 
implications, since LDAP is not trusted.  So there's not necessarily 
and evidence of this hidden recursion in the response, nor any 
security implication.  For OCSP, I didn't think recursion is 
supported in the response structure, so the issue there is moot. 
Finally, as I noted earlier, this is most importantly a DPV issue, 
since no trust is vested in a DPD server. Still, we have to decide if 
there is merit in allowing recursive syntax for DPD responses.

Since we don't trust DPD servers per se, the only issue I see here is 
whether the DPD server to which a request was made can return OCSP 
responses that were gathered by other DPD servers, without making 
that obvious to the client. I'll rely on Ambarish or Mike to answer 
that question, since I don't recall the format details well enough.

Steve

---

From: "Michael Myers" <[email-masked]>
Date: Fri, 12 Jan 2001 10:23:27 -0800

Steve,

> On Thursday, January 11, 2001 1:35 PM you wrote
>

Given that OCSP may in the long run wholly replace CRLs in some environments
it does see prudent that the DPD response structure enable this option.

With regard to client notification of a DPD server's response content, note
that BasicOCSPREsponse syntax requires inclusion of ResponderID, either by
name or key hash.  Either would enable a client to identify the source(s) of
information accumulated by a DPD server in its interaction with secondary,
tertiary, etc. DPD servers.

Mike

---

From: Stephen Kent <[email-masked]>
Date: Fri, 12 Jan 2001 18:18:34 -0500

Mike,

>tertiary, etc. DPD servers.

the question I asked was whether the OCSP response carried data that 
tied it to a requestor, not a responder. If not, then OCSP responses 
acquired by other DPD or DPV servers can be passed through 
transparently to the client. if so, then to make use of these 
responses we need to preserve more of the structure of the processing 
activities that otherwise could be opaque to the client.

Steve

---

From: Rich Salz <[email-masked]>
Date: Fri, 12 Jan 2001 19:56:33 -0500

> tied it to a requestor, not a responder.

Only if the requestor uses a nonce.
	/r$