Subject: Re: Open issue: DPV relay

From: Peter Sylvester <[email-masked]>
Date: Tue, 9 Apr 2002 14:52:11 +0200 (MET DST)

> 
> > If the final answer
> > MAY contain answer from other service, a client might get some idea,
> > but I don't think that this creates a problem.
> 
> The answer from a DPV server to an end-user client DOES NOT contain a signed
> answer from another server, but may contain some data from another server.
> The fact that that data comes from another server is NOT visible to the
> end-user client. 
It may be that we have a different idea of visibility. I don't mean
that the client has to understand where data come from and the
only authentication is from the initial service. 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

If this requirement is accepted by the group one can regards this
as a kind of visibility of relaying. 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.  
  
> > I agree that it is probably not necssary to make explicitely available
> > some information of the kind: "I have used a multicasting scheme among
> > servers X to Z or chaining to Y'.
> > 
> > The client or another relying party want to know whether it is
> > valid and (maybe) why the server believes so.
> > 
> > There may be: I have asked the following n servers and they all told me *no*.
> 
> All that complexity is not needed, there is a single signature visible and
> the names of the intermediate servers, if any, are not visible. These names
> are not necessary (a stop-loop mechanism can be implemented without them).

Signatures of CAs, CRL providers, OCSP providers may are also visible. 

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? 

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. 

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: Tue, 09 Apr 2002 15:13:32 +0200

Peter,

> only authentication is from the initial service. 

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

> My definition

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.   
 
> as a kind of visibility of relaying. 

There is no requirement for any visibility of relying.

> The DPV responses may concern

There is no need for any extra information. Complexity and over-engineering
should be avoided whenever possible.

> Signatures of CAs, CRL providers, OCSP providers may are also visible.

Not exactly: CA certificates, CRLs and OCSP responses may optionally be
returned.

> CRLs and others. Is *this* complexity necessary, if one only needs

See the rational explained above.

> decision almost MUST be thrown away, in particular when it is possible

This information is optional and MAY be requested by the client.

I hope these explanations will allow to close this issue.

Denis