Subject: Re: Open issue: DPV relay

From: Peter Sylvester <[email-masked]>
Date: Tue, 9 Apr 2002 18:59:37 +0200 (MET DST)

> 
> We both agree that authentication is only from the initial server, 
> so the client does not need to understand where the data comes from. 

Ok.  More, the client may not even need to know what the data *ARE*. 

> > My definition
> > of visibility is just that it is possible to determine all data
> > that have contributed to a decision, and this information may
> > include the fact that they had original been build by someone
> > else and confirmed by the DPV server.
> > 
> > Somewhat related to this : On last Friday Ambarish wrote:
> > 
> >   Hi Peter,
> >       I agree with your desire to have a DPV response included where
> >    one would allow CRLs or OCSP responses to be included to prove
> >    how a server obtained the status of a certificate.
> > 
> >   Regards,
> >   Ambarish
> 
> This is different. CRLs, OCSP responses and certificates may be needed in
> case someone else, not trusting the YES anwser from one DPV server, would
> like to verify the certificate against the same policy using another DPV
> server. All the information collected at the time of first validation is not
> necessarilly available, e.g. two years later, hence why this data may be
> useful. 

A DPV server can operate in a simular way as an OCSP. with a similar "trust
environment", creating a "positive response" instead of a negative negative 
response. 

A CA may just want to operate an 'authorized DPV responder' instead
of providing CRLs or OCSP. Note, that the various extensions for OCSP proposing
to turn the -*- answer into a + answer by including the cert or
something like that could be regarded as an implementation of DPV.  

> > If this requirement is accepted by the group one can regards this
> > as a kind of visibility of relaying. 
> 
> There is no requirement for any visibility of relying.

That's not what I said. There is also no requirement for complete
obscurity or information hiding. 
 
> > The DPV responses may concern
> > the same certificate or some certicate in the chain or else.
> > 
> > As far as I remember, I have not read an argument why such
> > a thing would create harm or would be undesirable for whatever
> > reason.
> 
> There is no need for any extra information. Complexity and over-engineering
> should be avoided whenever possible.

What do you call 'any extra information'? 'extra' related to some
information considered 'normal'? 

What has this to do with over-engineering and complexity? 

These information are not 'extra'. DPV responses may the only 
ones available to return a 'timely status' of the certificate like
a 'timely revocation information'. 
    
> > Signatures of CAs, CRL providers, OCSP providers may are also visible.
> 
> Not exactly: CA certificates, CRLs and OCSP responses may optionally be
> returned.
Sorry for having made a error in my previous phrase the 'are' should be 'be'.

So we agree, still where is the essential difference between a DPV
response and an OCSP response concerning their signature?

There is already a requirement: 

" For the client to be able prove to a third party that trusts the 
  same DPV server that the certificate validation was handled correctly, 
  the DPV response MUST be digitally signed."

which IMO means that the DPV response does not has a pure ephemeral status
but at least a similar characteristics as those of an OCSP response. 

> > Remember I said that "I agree that it is probably not necssary .."
> > 
> > Where do you see too much complexity: It is already complex to return a path,
> > CRLs and others. Is *this* complexity necessary, if one only needs
> > a yes/no/unknown answer?
> 
> See the rational explained above.

I still don't see where you see the complexity. DPV responses
may be given to other relying parties. Such a party must be 
able to validate it. It don't think that there is much code
complexity by allowing that the response itself may contain
a response as part of the justifications. 

I would think that there may be even simplicity If I only have 
to treat DPV responses for example.
 
> > Or, I fail to understand why some information that contributed to the
> > decision almost MUST be thrown away, in particular when it is possible
> > that it is important.
> 
> This information is optional and MAY be requested by the client.

Isn't this exactly what I am asking for. A DPV response may be
the only information available indicating that some intermediate CA
cert is valid. It MAY be optional returned when requested (or
defined as to be returned in the policy).    
 
> I hope these explanations will allow to close this issue.

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.

Encapsulating a "DPV response" in a OCSP response still 
remains an option anyway.  
  
> 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).
> > 
> > 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
>

---

From: Denis Pinkas <[email-masked]>
Date: Wed, 10 Apr 2002 16:36:19 +0200

Peter,

(text deleted)

> 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.
 
> remains an option anyway.

Encapsulating a "DPV response" in a OCSP response is out of the scope of
this discussion.

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

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 10 Apr 2002 16:02:21 +0100

Denis,

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

-- 
____________________________________________________________
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 17:18:11 +0200

Stephen,

> client but by some 3rd party? 

What do you call an evidence ? Is it the signed "yes" answer or the bunch of
certificates, CRLs and OCSP responses ? If it is the latter, then I agree.

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

We are not in that case, so this argumenation does not apply.

> against the original request.

Relayed responses, if any, are invisible to the first requester.

If, as mentionned earlier, an evidence is bunch of certificates, CRLs and
OCSP responses, then it is not the signed "yes" answer, i.e. the core of the
DPV response.

> Seems a bit confused to me (but then I'm often confused:-),

Indeed since your are using a term (i.e. evidence) that is not used in the
document.

Denis

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 10 Apr 2002 16:43:08 +0100

Denis,

Is the core of our difference that you consider that
showing a DPV request/response pair (say to an expert 
witness who'll then turn up in court) is not as meaningful as 
showing a bunch of certificates, CRLs and OCSP request/response
pairs (to that same expert witness who'll then turn up in 
court)? [And s/in court/in an arbitration meeting/ or 
whatever else you prefer which avoids us discussing how 
legal things happen.] 

My position would be that one can be just as meaningful 
as the other, depending on the context, and that the DPV
protocol MUST be able to be used in contexts where the
DPV request/response are (according to me) as good as 
the certificates/crls/ocsp stuff.

> certificates, CRLs and OCSP responses ? If it is the latter, then I agree.

Practically speaking any data structure can provide some level of evidence,
certificates, CRLs and OCSP responses included, but I'd also include DPV
request/response pairs (assuming good protocol design) as being pretty
much as good in some contexts.

> We are not in that case, so this argumenation does not apply.

We are in that case, so it does apply. 

(See - didn't that bring the discussion along nicely:-)

> Relayed responses, if any, are invisible to the first requester.

We're discussing whether this should be the case or not.

> OCSP responses, then it is not the signed "yes" answer, i.e. the core of the

I can't parse that, but I think its ok if I've identified where
our difference lies.

Stephen.

---

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

Stephen,

> whatever else you prefer which avoids us discussing how

No. It is not the core of our difference.

A court may find some DPV responses from some specific DPV servers 
as appropriate, but this cannot be a general rule. So when it is not
appropriate, certificates and revocation stauts information will be used.

> as the other, depending on the context, 

Correct.

> and that the DPV

So we both agree. :-)

> much as good in some contexts.

No: the client nor a disputing party will not necessarilly trust it. The
only thing that the first DPV server knows is that it is trusted by that
client, but this first DPV server is unaware of any other DPV server trusted
by that client. The only information that is not disputable is: the
certificates, CRLs and OCSP responses.

> I can't parse that, but I think its ok if I've identified where

The difference lies in the trust conditions. I believe that trust conditions
are *not* transitive and thus would a DPV response come from a another
server, it is unlikely that the client would trust it. Now, if the server
trusts it, it is its problem and becomes fully responsible of the final
response. If it wants to make sure that everything is correct, then it
should ask for and check itself the original data used to validate the full
path: all certificates, CRLs and OCSP responses.

I hope this helps.

Denis