RE: DPD & DPV requirements - Let us Recurse

[Stephen Kent <kent@xxxxxxx>]

Peter,

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

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.

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

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