RE: DPD & DPV requirements - Recursion Issues

[Peter Sylvester <Peter.Sylvester@xxxxxxxxxx>]

> >
> >I am not the best candidate to answer questions about DPD. I am mainly
> >interested in DPV (as some might imagine).
> >
> >Anyway, if I understand Mike Myers remark correctly, if a DPD server
> >is essentially untrusted, then it could basically just rewrite a relayed
> >response.
> 
> Yes, but that will be caught by the client of a DPD server, even a 
> DPV server that acts as a DPD client in performing it's function, as 
> Steve Hanna suggests.
> 
> >A DPD server might have performed an OCSP check or a DPV check (for example
> >to validate a CA cert.) The response should be sent back to the DPD
> >client, this can be used by the client to make a decision about the
> >acceptablity of the path.
> 
> An OCSP response if fair game. but I'm not sure I want the DPV 
> response to be used recursively, yet.

Hm, 

A DPV response has such an importance that it seems useful to keep
it as is when used by a client, even if this client uses the
content of the response to create some other statement or
whatever to its type of client. 

There are at least two elements in the response of a DPV:

- A authoritive statement about whether a cert is good or not.
- And a list of reasons, starting with the cert chain, crls,
  Ocsp responses. 

If a DPV server has acted as a DPV client either in delegation to
validate the same initial certificate, or to validate for
example the first CA cert in chain not just by using OCSP but by
using DPV, then not allowing it, *MUST NOT* be included,
in a response means what?

CA certs, CRLs, OCSP reponses are statement about the validity,
they already have a different nature, a DPV response doesn't
seem to be that far. 

Again, if an OCSP responder policy explains that
the actual status doesn't just say 'not revoked' but
'good and existing', then this statement is essentially
the response of a DPV.

Peter