Subject: Re: Open issue: DPV relay

From: Peter Sylvester <[email-masked]>
Date: Mon, 8 Apr 2002 18:10:23 +0200 (MET DST)

Denis,

fortunately I know how to interprete 'French comments', I hope that
you can interprete 'German comments', for the others, see PS. :-)

> 1) "I see no reason for the client to be made aware of an chaining or
>     multicasting".

I am not sure whether you can hide this completely. 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. 

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*.
 
> 2) "I do not think that we should include referrals in the DPV system 
>     at all".
I am just a little bit careful asking about the meaning of this
sentence. 

Do You want a specification: A conformming protocol MUST not specify
any method that implies whatever kind of referral, or do you 'just
don't care', i.e. a protocol MAY implement an extension to be
used among consenting client/servers? see below.  

> 
> Now, taking the scenario depicted by Peter, with some important changes:
> 
>  End user A asks server S1 "validate cert".
>  client S1 asks server S2. 
>  server S2 responds : don't know. 
S2 answers : Don't know, please go to service S3, here is a trustworthy cert of S3.

>  client S1 asks to another DPV server that it trusts, e.g. server S3.
>  server S3 responds to client S1 : the certificate is valid.
>  server S1 responds to end user A: the certificate is valid.
> 
> This is not referral, but it works fine with a list of servers trusted 
> by server S1.

Indeed, it works fine. But the *important change* removes the problem
of the situation that may be interesting. 

One of the questions here is whether the protocol MAY/SHOULD/MUST provide for a
means to transfer some 'trust', i.e. to inform a client (maybe not to real 
end users if they can be distinguished) about the trustworthiness of another server
(for a particular request). 

I wouldn't mind about MAY if simplicity of a real end user client is
guaranteed, i.e., in general, an end client SHOULD not be required to make
more than one request to obtain a result. 

In general: Do we have to put into this specification protocol
features that 'MAY' exist? 

Peter

PS:

French comment : 'no, absolutely unaceptable'  
                    ==> let's talk, more work is needed
                 'yes, that's already something'  
                    ==> go implement that, no need for discussion

German comment : 'No, absolutely unacceptable'
                    ==> no need for discussion, throw it away.
                 'Yes, that's already something'
                    ==> let's talk, more work is needed

If I remember it correctly, at least the ar of 1870 was created
by a voluntary provocation of such a misunderstanding. 

"We ask you to consider to dismantle the Strasbourg garnison".
"No way".
"ok, then we might consider take the whole North East of France"
"That is an absolutely unacceptable declaration of war."
'Here you have it".

---

From: Denis Pinkas <[email-masked]>
Date: Tue, 09 Apr 2002 12:24:16 +0200

Peter,

(text deleted)

> I am not sure whether you can hide this completely. 

We can certainly hide this completely from the end-user client point of
view.

> If the final answer

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

> I am just a little bit careful asking about the meaning of this

See my response to Steve on that topic.

Denis

> Peter

(text deleted)