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

From: Peter Sylvester <[email-masked]>
Date: Mon, 8 Jan 2001 12:51:03 +0100 (MET)

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

---

From: Stephen Kent <[email-masked]>
Date: Mon, 8 Jan 2001 12:02:45 -0500

Peter,

>been used to validate it, and the server believes that this chain

The interesting part of the notion is using a common representation, 
which can then be translated into human readable language, to express 
the validation chain assertions, especially when the validation 
process is incomplete, or not exact, e.g., outdated CRLs.

>another verifier of the enhanced signature.

Well, there is already a suggestion (that I need to look into 
further) that proxied OCSP responses may pose problems. if one has to 
assemble a mix of serial and parallel signed responses to satisfy a 
query, that adds complexity both syntactically and semantically. But, 
for the most part, my allusion to R&D issues has to do with the 
problems that arise when the revocation status data is not quite 
perfect and one wants to respond with something more that "NP" and 
with the human interface presentation issues.

Steve