RE: DPD & DPV requirements - Let us Recurse

[Peter Sylvester <Peter.Sylvester@xxxxxxxxxx>]

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

Isn't part of this 'interesting notion' the cert chain itself. The
certificate chain return by a DPV server is the chain that has
been used to validate it, and the server believes that this chain
is valid. 

If the service is implemented using some relaying, such that a 
server becomes a client of someone else, what research problem
is there that the intermediate server/client wants to provide the
results? If for the initial client the result of the validation
becomes something that can be stored somewhere, e.g. similar to
an OCSP response stored in the SMIME/ETSI signature format stuff,
then essentially this client becomes an intermediate server for
another verifier of the enhanced signature.