Subject: Re: Open issue: DPV relay

From: Denis Pinkas <[email-masked]>
Date: Fri, 12 Apr 2002 16:46:07 +0200

Thanks to numerous private e-mail exchanges with Stephen Farrell 
(thanks Stephen !) we both came to an agreement on additional text 
to address relaying, re-direction and multicasting.

So I submit this text to the list.

Denis

====================================================================

4.2. Relaying, re-direction and multicasting.

Protocols designed to conform to these requirements MAY include 
optional fields and extensions to support relaying, re-direction or 
multicasting features. DPV clients are NOT REQUIRED to support relay, 
re-direct or multicast, therefore clients or servers which do not 
support such features still conform to the basic set of requirements. 
DPV servers are NOT REQUIRED either to support relay, re-direct or 
multicast.

1. Where relay or re-direct mechanisms are supported by a server 
   a mechanism to detect loops or repetition SHOULD be supported.

2. Where a DPV server chooses to re-direct the request to another
   DPV server (i.e. chooses to provide a referral), a mechanism to 
   provide information to be used for the re-direction SHOULD be 
   supported. Note: In case where information to be used for the 
   re-direction is sent back, clients are NOT REQUIRED to interpret 
   that information (but MAY do so).

3. These features MAY be supported by using additional parameters
   in the request and/or response. Clients and servers that do not
   support such additional parameters MUST still be able to use/offer
   DPV service. In this way, implementers need not understand the 
   semantics of any such extensions.

====================================================================

---

From: "Michael Myers" <[email-masked]>
Date: Sun, 14 Apr 2002 19:37:55 -0700

Denis, Stephen:

Good work.  I agree with the text as submitted.

Mike

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Denis Pinkas
> Sent: Friday, April 12, 2002 7:46 AM
> To: pkix
> Subject: Re: Open issue: DPV relay
>
>
>
>

---

From: "Housley, Russ" <[email-masked]>
Date: Mon, 15 Apr 2002 09:26:22 -0400

I am strongly opposed to any requirements regarding re-direction (a.k.a. 
referrals) or multicasting.  These services would add considerable 
complexity to the client side of the interface, making support for 
lightweight clients more difficult.

I have specific comments below...

>DPV servers are NOT REQUIRED either to support relay, re-direct or

I can support relaying (a.k.a. chaining) because it does not add complexity 
to the client.

These are not protocol requirements.  They are implementation requirements, 
and we are not defining a protocol in this document.

I prefer:

Protocols designed to satisfy these requirements MAY include mechanisms for 
relaying.  However, such protocols MUST NOT include mechanisms for 
re-direction or multicasting.  Re-direction or multicasting mechanisms 
would add considerable complexity to the client side of the interface, 
making support for lightweight clients more difficult.

>    a mechanism to detect loops or repetition SHOULD be supported.

I think that SHOULD ought to be changed to MUST.
I think that re-direct ought to be deleted.

>    that information (but MAY do so).

I think that this should be deleted.

>    semantics of any such extensions.

I think that additional ought to be changed to optional.

Russ

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 15 Apr 2002 14:54:29 +0100

Russ,

It seems that essentially you want to change "protocols MAY re-direct/m-c" 
into "protocols MUST NOT re-direct/m-c", right?

- I fail to see how the MAY option adds complexity to clients since 
presumably the protocol you like that meets the requirements won't 
take up the "MAY" option and it won't be an issue for such clients.
Even if a conforming protocol does include re-direct, the text 
proposed ensures that there is mandatory impact on clients.

- Allowing re-direct/m-c does allow for some interesting server to
server interactions (in an IMO clean way) as previously discussed on 
the list. I see no reason to prohibit those or cause vendors to
re-invent or corrupt their use of a dpv protocol in order to 
support such cases.

- We can in any case judge relative compexity issues (only?) when 
concrete protocols are being compared against these requirements.

So, all in all, I see no reason to forbid protocols to support these
mechcnisms and some reasons to allow protocols to do so and no reason
at all to make a premature decision on this.

Regards,
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: "todd glassey" <[email-masked]>
Date: Mon, 15 Apr 2002 09:13:40 -0700

Russ -
----- Original Message -----
From: "Housley, Russ" <[email-masked]>
To: "pkix" <[email-masked]>
Sent: Monday, April 15, 2002 6:26 AM
Subject: Re: Open issue: DPV relay

> I can support relaying (a.k.a. chaining) because it does not add
complexity

Doesn't chaining change the trust model since it will now not be clear at
which link along the chain any trust-transaction went green or red. My take
is that DPV still is far from being done since the use model is in conflict.

---

From: "Housley, Russ" <[email-masked]>
Date: Mon, 15 Apr 2002 13:31:44 -0400

Todd:

>is that DPV still is far from being done since the use model is in conflict.

No.  The client gets a response from the server that it sent the request to 
in the first place.  The response is signed, and it can be validated with 
the expected trusted public key.  The fact that the DPV server used the 
resources of other DPV servers to fulfill the request is transparent to the 
client.  Of course, the first DPV server administrator must do some 
checking into the subsequent DPV servers in the chain before configuring it 
to forward requests.  That is, the subsequent DPV servers must meet the 
requirements of the validation policy.

Russ