RE: DPD & DPV requirements - Let us Recurse

[Peter Sylvester <Peter.Sylvester@xxxxxxxxxx>]

> 
> Peter,
> 
> I thinbk we are in agreement that the set of data returned by a DPD 
> or DPV server will be limited in scope and well defined, i.e., 
> sequences of certs, CRLs, and OCSP responses are the initial set. 

s/i.e./e.g./  


> Whether we allow recursion and allow DPV responses is still an open 
> question.

As you say there is 'recursion' and 'DPV responses'.

- If we allow an OCSP response as a statement about a cert status
  I don't see whether why DPV status is not possible, in particular
  if OCSP is the base protocol, one could consider that we already
  a this available.  

- Indeed, it remains the question whether we want these services
  just relay the same request to another server, and what should
  be the request and response format changes, in particular in
  order to provide for loop detection. 

For the second point another strawman requirement:

  In some environment a DPV server may be operated as a relay/broker
  to other services. In order to cover possible misconfiigurations
  in such situations, the protocols must provide an efficient means
  to detect request loops. hop counts or 'Received and relayed by XXX'
  trace elements are possible means. 

  It is up to the relaying server how to interprete and transform
  a response from another server. In any case a DPV must add apply
  its own authentication mecanism, e;g. its own signature. Possible
  reponses include an encapsulation of the initial reponse, or simple
  replacement of the securiy envelope.