Subject: RE: DPD & DPV requirements - Let us Recurse

From: Peter Sylvester <[email-masked]>
Date: Fri, 5 Jan 2001 15:31:46 +0100 (MET)

> 
> Steve Kent's DPD/DPV requirements, the SCVP proposal, and the OCSP DPD
> proposal all permit OCSP responses
> to be returned to the client as revocation status data.  Presumably in each
> case this refers to OCSP v1 basic responses,
> at least.  This is all well and good, but would it not be desirable to also
> permit recursion in the DPD response?  That is, the DPD
> response might include an embedded DPD response from another server.  Among
> other benefits, this would preserve the 
> timestamp (if any) on the embedded DPD response.
>  

I have some feeling that handling DPV and DPD at the same time
is not an extremely good thing, there may be well some 
requirements that apply for both, in this case I think that
these are general requirements for almost any secure protocol.
Furthermore DPV and DPD seem to be at different (sub)layers,
e.g.., a DPV layer could run a loop towards a DPD server. 

The text mentions several usage environments, public, private
and heterogeneous. 

There was a question recently about OCSP mentioning a similar issue:

A DPV server in any environment should be able to delegate part of the
service to another server, it should be possible that the response
delivered to the client include the response of the delegated/relayed
request, and all elements that can be used to determine the
authenticity of the response, e.g., signatures from the
primary server (as a coutersignature or as a parallel signature),

It has been mentioned that the response is to be time stamped and used
in order to validate a long term document etc. It seems important to me
that the client can use the response not only to make a decision, but
also to have all information about why this decision had been made.
 
Thus, a client can create a statement saying: 
" I accept this certificate because my server told me that it is
  good, and he provides the following justifications: ..."
instead of:
" I accept this certificate because my server told me that it is
  good, if you want to know wy, go ask elsewhere" (how?).

In some contexts this is related to relaying: A company server
tells that a cert is good because a request to a remote server
(from another company or elsewhere) has been made, i.e.: the response
says something like: "We, the humble XXX compnay server think that
the certificate CCC is good because we have this validity
statement from XYZZY according to policy PPP...".

PS

---

From: Stephen Kent <[email-masked]>
Date: Fri, 5 Jan 2001 13:29:02 -0500

Peter,

I am open to the suggestion that we further separate DPV vs. DPD 
requirements, to make each clearer, although my impressions, after 
some thinking, are that these two types of servers are more alike 
than I had originally imagined.

Returning info that explains why a server believes that the returned 
data supports validation is an interesting notion. The first example 
of that I saw was in work performed by colleagues here at BBN, on a 
project calls IOS, in the early 90s, where servers did that.  But, I 
think this is still an R&D topic for now, not yet ready for 
standardization.

Steve

---

From: "Michael Myers" <[email-masked]>
Date: Fri, 5 Jan 2001 18:18:35 -0800

Steve,

It is precisely this overlap that led to the existence and architecture of
the current DPV and DPD drafts, namely that a DPD server was simply tapping
into the path discovery logic that a DPV server must execute.

Care must taken however as we go forward with high-level requirements to
ensure that a DPD server delivers up that path a DPV server would have used.
Or are we otherwise comfortable that some ambiguity may emerge?  This was an
open question that we as DPV and DPD authors were and are grappling with.

Mike

-----Original Message-----
From: Stephen Kent [mailto:[email-masked]]
Sent: Friday, January 05, 2001 10:29 AM

. . .

---

From: Stephen Kent <[email-masked]>
Date: Mon, 8 Jan 2001 11:30:14 -0500

Mike,

>open question that we as DPV and DPD authors were and are grappling with.

We'll see what the group says, but for now I am assuming that 
ASN.1-based DPD and DPV servers will exhibit considerable mechanism 
and maybe message format overlap.

Steve