Subject: RE: Open issue: DPV relay

From: "Linn, John" <[email-masked]>
Date: Wed, 10 Apr 2002 11:16:55 -0400

I agree with Stephen's observation.  Within a DPV environment, much of the
rationale for being (optionally) able to return information received from
other servers, rather than simply distilling it, is to be able to support
audit and dispute resolution.  This would normally happen on an exception
basis, and its verifier may well be different from the client that requested
the DPV response.  

--jl

> -----Original Message-----
> From: Stephen Farrell [mailto:[email-masked]]
> Sent: Wednesday, April 10, 2002 11:02 AM
> To: Denis Pinkas
> Cc: Peter Sylvester; [email-masked]
> Subject: Re: Open issue: DPV relay
> 
> 
> 
> 
> Denis,
> 
> > I would disagree. Let me explain why. The requester only 
> trusts the DPV
> > server that it has queried. The DPV server may trust any 
> server it likes,
> > but the client does not care: the client does not 
> necessarilly trust them.
> > The original server is the only one responsible for the 
> "valid" signed
> > response. So if a DPV response from another server were 
> included as a proof
> > of the "valid" response, it would not be a proof for the 
> client. The client
> > needs a proof from first hand, i.e. a proof that is not 
> disputable. This can
> > only be the original certification path, the original CRLs 
> and the original
> > OCSP responses, with all the proofs that the CRL Issuers 
> and the OCSP
> > responders are indeed empowered to provide that information.
> 
> But isn't it likely that the evaluation of the evidence happens
> at dispute-resolution time and is done not by the run-time 
> client but by some 3rd party? If not, then the client has to
> check everything at run-time; if so, then the fact that the
> client doesn't trust the relayed-to server is moot (what 
> matters is what the evidence evaluator thinks).
> 
> I would agree though that including just a dpv response as evidence
> might be misleading unless all relayed responses can be matched
> against the original request.
> 
> Seems a bit confused to me (but then I'm often confused:-),
> Stephen.
> 
> Denis Pinkas wrote:
> > 
> > Peter,
> > 
> > (text deleted)
> > 
> > > I refer to my proposal to change the text saying that
> > > that among the optional returned infos like paths CRL,
> > > OCSP responses, there may alos occur DPV responses.
> > 
> > I would disagree. Let me explain why. The requester only 
> trusts the DPV
> > server that it has queried. The DPV server may trust any 
> server it likes,
> > but the client does not care: the client does not 
> necessarilly trust them.
> > The original server is the only one responsible for the 
> "valid" signed
> > response. So if a DPV response from another server were 
> included as a proof
> > of the "valid" response, it would not be a proof for the 
> client. The client
> > needs a proof from first hand, i.e. a proof that is not 
> disputable. This can
> > only be the original certification path, the original CRLs 
> and the original
> > OCSP responses, with all the proofs that the CRL Issuers 
> and the OCSP
> > responders are indeed empowered to provide that information.
> > 
> > > Encapsulating a "DPV response" in a OCSP response still
> > > remains an option anyway.
> > 
> > Encapsulating a "DPV response" in a OCSP response is out of 
> the scope of
> > this discussion.
> > 
> > > > Denis
> > 
> > > Since you haven't commented the next paragraph may I assume that
> > > this is ok with you?
> > 
> > > > > I think the general principle should be that there is one mode
> > > > > that all information essential to understand what has 
> contributed
> > > > > to the final decision must be made available to the client.
> > > > > (Not necessarily understood by the client).
> > 
> > No. It is always necessary to provide a yes/no/unknown 
> answer (or an error).
> > 
> > It is optional to provide all the information essential to 
> test again the
> > certificate validity, should another party not simply trust 
> the signed "yes"
> > answer. It is certainly not necessary for the client to 
> understand what has
> > contributed to the final decision.
> > 
> > Denis
> > 
> > > > > I would also agree, that only necessary information 
> should be made
> > > > > available. It may be not necessary to inform:
> > > > >
> > > > > - Yesterday I have made three unsuccesseful attempt 
> at time1 2 3,
> > > > >   the last one finally succeed by using an internet connect to
> > > > >   address a.b.c.d using DPV protocol over OCSP, ...
> > > > >
> > > > > Peter
> 
> -- 
> ____________________________________________________________
> Stephen Farrell         				   
> Baltimore Technologies,   tel: (direct line) +353 1 881 6716
> 39 Parkgate Street,                     fax: +353 1 881 7000
> Dublin 8.                mailto:[email-masked]
> Ireland                             http://www.baltimore.com
>

---

From: Denis Pinkas <[email-masked]>
Date: Wed, 10 Apr 2002 18:02:51 +0200

John,

> audit and dispute resolution.  

You address two different needs:

  1) audit,
  2) dispute resolution.

I have addressed the later in my mail exchanges with Peter. 
So let us address the former.

There is no requirement for an audit purposes in the current document. The
DPV server is responsible for providing a right answer. If it is not able to
do so, it shall answer "unknown". The server may keep anything it wants in
audit trail, but there is no requirement to provide "audit information "
associated with the response. Currently the only requirement, in addition
with a signed "yes" answer, is:

"The DPV request MUST allow the client to request that the response 
include the certification path and revocation status information used 
by the DPV server to process the request." 

Denis

> This would normally happen on an exception