RE: DPD & DPV requirements - Let us Recurse

[Peter Sylvester <Peter.Sylvester@xxxxxxxxxx>]

> 
> 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