Subject: Open issue: DPV relay

From: Tim Polk <[email-masked]>
Date: Thu, 04 Apr 2002 18:11:28 -0500

Peter Sylvester has stated a requirement for DPV servers to relay requests 
to one another:

 >
 >There is a requirement, similar as for OCSP caches,
 >that server just relays a request to another. This had been
 >discussed several times, the differences had only been to
 >what degree the relaying should become visible; whether one
 >server can rewrite/resigns the answers of another etc.
 >Relaying via cache is an obvious feature in many OCSP implementation,
 >how do they protect itself against loops between two servers?
 >

I believe this is an open issue, and would like to start a new discussion 
thread limited to this topic.

As I understand Peter's scenario, there are three mutually trusting DPV 
servers.  If a server cannot satisfy a request directly, it may relay the 
request to a different server.  We'll assume the server is smart enough not 
to relay a request back to the requester.  (That is, if server A relays a 
request to Server B, B may relay it to Server C but not A.)

(1) Assume Alice requests a valid path for Bob's certificate from Server A, 
when none exists.
(2) Server A relays the request to Server B, since it cannot satisfy it 
directly. (A could have chosen Server C; it is irrelevant.)
(3) Server B relays the request to Server C, since it cannot satisfy it 
directly.  (C could not choose A, since it was the requester.)
(4) Server C relays the request to Server A, since it cannot satisfy it 
directly.  (A could not choose B, since it was the requester.)

At this point, either A must maintain state and recognize that the request 
has cycled around or the protocol has to handle this by maintaining a 
history list.

Peter, please confirm that I have characterized the problem correctly (or 
post the right scenario)!  I am not personally convinced that blind 
relaying amongst DPV servers is a requirement.

IMHO, DPV relaying would be limited to the scenario where each Server was 
authoritative for a particular community (perhaps based on privately held 
status information).  Alice directs all requests to Server A to simplify 
her life.  Server A would be able to determine which server (B or C) could 
possibly satisfy the request based on Bob's certificate.

Even though relaying occurred, Server A acted as a simple DPV client, 
imposing no additional requirements...

Thanks,

Tim Polk

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 05 Apr 2002 14:21:09 +0100

*If* relaying support/capability is to be considered as a 
MUST/SHOULD/MAY requirement for a DPV protocol, then should 
re-direction be handled similarly? (Note: I'm not proposing 
that it should be, just asking!)

By re-direction I mean:

Alice: Hey Bob - is this key good?
Robert: Dunno Alice - but Charlie might know.
Alice: Hey Charles - is this key good?
Chaz: Yep.

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: Fri, 05 Apr 2002 15:32:38 +0200

Steve,

> Alice: Hey Charles - is this key good?

This is not relaying, but referral. The issue was about relaying, 
not referral. Referral is not supported. 

Denis

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 05 Apr 2002 15:04:35 +0100

Denis,

Denis Pinkas wrote:
> This is not relaying, but referral. 

Depends whether you're of DAP or HTTP vintage I guess:-)

> Referral is not supported.

That is one possible answer and may well be the concensus, I guess
we'll see. 

In any case, re-direct/referral would only be an issue depending
on what happens with relaying is my guess.

Stephen.

---

From: "Michael Myers" <[email-masked]>
Date: Fri, 5 Apr 2002 08:43:26 -0800

Tim,

FWIW I think relay should be supported.  Is the core question
stateful servers vs. stateful protocol?

Mike

Michael Myers
t: +415.819.1362
e: mailto:[email-masked]
w: http://www.traceroutesecurity.com

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Tim Polk
> Sent: Thursday, April 04, 2002 3:11 PM
> To: [email-masked]
> Cc: Peter Sylvester
> Subject: Open issue: DPV relay
>
>
>

---

From: "Housley, Russ" <[email-masked]>
Date: Fri, 05 Apr 2002 11:54:39 -0500

Steve:

In the X.500 directory, they two communication models are called chaining 
referrals.  Peter has asked for chaining support.  You are asking whether 
referrals should also be supported.

I can see cases where chaining might be helpful.  It does not change the 
client's trust model.  It asks a particular DPV server for a response, and 
it gets one (signed by the same server that it asked).

I think that referrals complicate the trust model.  The client asks one DPV 
server, then that server suggests that a different server might be better 
able to help.  If the client chooses to ask that server, it will get back a 
response signed by the second server.  Does the client trust it only 
because the first server made a referral?  What information need to be 
stored by the client to prove that it was referred to this server? All of 
this is more complication than I want.

Russ

---

From: jim <[email-masked]>
Date: Fri, 05 Apr 2002 14:50:02 -0500

A small addition, but X.500 directories also have the ability for multicasting in
which case a number of other directories are queried for a certificate at the same
time.  Multicasting requires the greatest amount of directory and system overhead,
but gets the quickest returns; where chaining requires the least and referral is
the slowest, so there should be support for all three in the DPV capability.  There
are no associated trust issues with use of either of the three methods as far as I
know.
Jim

---

From: "Housley, Russ" <[email-masked]>
Date: Fri, 05 Apr 2002 15:42:31 -0500

Jim:

I am not talking about trust in the X.500 system.  I am talking about trust 
in a DPV server.  In my mind, the client asks one DPV server to perform an 
action.  The response should come back, signed by that DPV server, or it is 
an error from the client's perspective.

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

I do not think that we should include referrals in the DPV system at all.

Russ

---

From: jim <[email-masked]>
Date: Fri, 05 Apr 2002 17:27:18 -0500

Russ,
    But the exact point is that if you decide that creating trust with directories
is the key instead of trust with the certificate holders and issuers, then the only
type of directory interaction that can occur is referral, which increases system
overhead, delays based on directory response times, and a general inability to grow
large systems in which any individual cross-certifying PKI has a single directory
to address.  Every individual PKI implementation would have to have not only a
central directory, but also border directories and each border directory would have
to hold the same level of trust as the central directory.  This implies constant
near-real-time updating of border directories or the threat of failed validation.
Help me to understand how you envision the directory system that successfully can
respond to a multitude of simultaneous or near-simultaneous requests for
validation.  Thanks.  Feel free to reply just to me if you wish as not everyone may
be interested from this point forward.
Jim

---

From: "todd glassey" <[email-masked]>
Date: Fri, 5 Apr 2002 15:52:17 -0800

Russ is 100% dead on  but this is about the mechanics of the use model more
than anything - let me demonstrate...

----- Original Message -----
From: "Housley, Russ" <[email-masked]>
To: "jim" <[email-masked]>
Cc: <[email-masked]>; "Tim Polk" <[email-masked]>;
<[email-masked]>
Sent: Friday, April 05, 2002 12:42 PM
Subject: Re: Open issue: DPV relay

> I do not think that we should include referrals in the DPV system at all.

The only way this would not want to be true is if the trust model between
the requesting agents and the supplying agents had a pre-existing agreement
that the trust supplying agent could look beyond its own services as sources
of the trust model its looking for from this DPV server. It would then stand
as a referred trust provider when it cannot satisfy the trust request
itself.

In fact from a use model perspective, it would seem that only the client
could authotize this  for privacy reasons, and it seems that it would need
to be on a per transaction basis (I.e. the Trust provider says " my trust
processes cannon fulfill this request so I have passed it onward to someone
that can" ... the only problem is that you run the potential that the  next
link in the trust envelope would also not be able to satisfy this request
either or coupdl get locked in a loop... so where does it stop???)

The "what" of what you have now is a situation where the referring agent is
going around and shopping for an external DPV agent who can and is willing
to satisfy this trust validation request.  And this seems at best kinda
clunky and potentially a real problem  over privacy and context information
from the actual agent requesting this validation service.

I suggest that becuase of this, that unless specifically authorized or
requested from the client, that the DPV services should be restruicted to
stay on a single platform... and it be the Client's responsibility to
hierarchicly check out the trust element in question.

> Russ

SNIP

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 08 Apr 2002 11:13:12 +0100

Hi Russ,

I do tend to agree that re-direct/referral carries some complexity 
and therefore adding it might not be warranted at this stage. However,
if we are adding relay (though I'm not sure what requirement on a 
protocol is being added - is it: "MAY have the ability to be used in 
relaying fashion"?) then thinking about re-direct/referral seems
appropriate.

I would think that the closest-to-real use case for this is actually
a combination of relaying and referral as in:

Alice -> Bob - is this a good key?
    Robert -> Charlie - is this a good key? (relaying)
    Chaz -> Robert - I dunno, ask Denis (re-direct/referral)
    Robbie -> Denis - is this a good key?
    Denis -> Rob - I strongly disagree (with apologies:-)
Robert -> Alice - Nope

That has some nice properties for hiding internal structure, using
fewer trust points, avoiding firewall problems, not making the client
more complicated than necessary etc that I think you don't get with 
relaying alone.

I also agree that the following is an intresting question that 
would have to be answered by any protocol that claimed to support
re-direct/referral: "if I trust you for DPV, does it follow that
I trust you to tell me who else I trust for DPV?". On the one
hand the client is no more exposed since the first DPV server can 
always cheat, on the other hand, this smacks of some meta-protocol, 
so I don't know the answer. 

Cheers,
Stephen.

---

From: "Housley, Russ" <[email-masked]>
Date: Mon, 08 Apr 2002 08:56:14 -0400

Jim:

You missed my point altogether.

This discussion has nothing to do with directories.  We are discussion DPV 
servers.  The DPV server will do to a directory to obtain certificates and 
CRLs, go to OCSP responders, and (if needed) go to other DPV servers.

In DPV, we only want to support a chaining model in the DPV client to DPV 
server communication.

Russ

---

From: Stephen Kent <[email-masked]>
Date: Mon, 8 Apr 2002 23:52:41 -0400

>so I don't know the answer.

There are a few issues here:
	- should DPV servers support relaying requests?
	- should DPV servers support referral among servers?
	- should DPV servers refer clients to other servers?

The first two facilities, if done in a fashion invisible to the 
client, add no complexity to the client and might even be supported 
by a different protocol. Of course, if we choose to make the fact of 
relaying or referral visible to the client, this argument no loner 
applies. (Which is not the same as having evidence of the relay or 
referral contained in an opaque blob of bits returned by the server.) 
The last does impinge on the simplicity of the client, and for that 
reason alone I would argue against any explicit provision for it in 
the client/server protocol, consistent with our broader goals for 
this protocol.

Steve

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 09 Apr 2002 10:51:05 +0100

Steve,

>         - should DPV servers refer clients to other servers?

A good list. (But I interpret the 2nd one above as being 
sufficient to support the use case I described - let me know
if I'm misinterpreting you.)

> referral contained in an opaque blob of bits returned by the server.)

I agree with the above too. For clarity, I'm interpreting the term
"client" in the above to cover the Alice in my example but not the 
Bob, even though Bob also has a DPV client built into his backend 
(which suggests rude things that could be said about DPV:-). So Bob's 
built-in DPV client is a "special" one that might support 
re-direct/referral, even though Alice's DPV client doesn't.

> the client/server protocol, consistent with our broader goals for

So, in requirements language I guess I'd be arguing for something 
like:

- A protocol SHOULD NOT require DPV clients to support relay or
  re-direct (aka chaining or referral)
- A protocol MAY require DPV servers to include support for 
  relay and/or re-direct (aka chaining and/or referral)

Is that reasonable?

Stephen.

---

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

Steve,

(...)

> by a different protocol. 

Relaying may indeed be supported in a fashion that is invisible to end-user
clients. So I agree with the first statement. It is possible for relaying
servers to implement a stop-loop mechanism. In order to close this issue, 
I have already proposed the following addition:

" In case a DPV server chooses to relay the request to another server 
using the same protocol, a method to detect loops MUST be supported 
by that relaying server."

However, for the question of supporting referrals, if we go back to the
trust model problem, an intermediate server has to make its own decision 
to trust or not to trust a referral: trust is NOT a transitive property. 
Yesterday I suggested to use a simple model where the client redirects 
the request to another trusted server. If a referral is given back, then 
the client has still to make its own decision of whether or not it shall 
trust that other server. It must do that using some local information. 
There are two bacic ways to make that decision:

1) it is one of the names from a list of servers, certified by a CA under
   some root CAs,

2) that server has some properties, e.g. its certificate is related to some
   trusted root CA and is issued under some certificate policy. 

In the first case, no referral is needed. In the second case, walking down a
certificate tree looking for certificates with that property would do the
job in a less easy way, but would do the job as well. 

Unless we would add some flag (to be used by intermediate servers acting as
clients) asking for referrals to be sent back (whenever possible) in the
form of a certificate, a name and/or a URI, referrals cannot be supported 
in a fashion invisible to end-user clients.

Denis 

> Of course, if we choose to make the fact of

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 09 Apr 2002 12:20:32 +0100

Denis,

> to trust or not to trust a referral: trust is NOT a transitive property.

True in general, but in this case? Take the example I gave, where Charlie
re-directs/refers to Denis. In that case Charlie is already completely
trusted by Bob to answer the question since Charlie can give whatever
answer he likes. The only controls on Charlie are accountability schemes
(like logging signed responses), which apply equally to a response
containing a re-direct/referral.

In other words, I don't see how transitivity applies here. (Or more
crudely: Charlie can already shaft Bob, what does it matter if he
chooses to do it in a complicated, rather than a simple, manner?)

One way to convince me you're right woiuld be to show a difference
between two scenarios, both with a bad-guy DPV server, but where
one scenario supports re-direct/referral and the other doesn't. Right
now, I can't see any difference. (I could see a differnce if the bad-guy
DPV server were allowed to annouce to other servers which names/certs/keys
he's authorative for, and where they were forced to belive the bad-guy,
but I don't think anyone's proposed that.)

> 1) it is one of the names from a list of servers, certified by a CA under

Hmm... are we trying to get a DPV server to distinguish a re-direct/referral 
*instruction* response from re-direct/referral *advice* response? Sort of a
half-way house isn't it, but possibly useful I guess.

> job in a less easy way, but would do the job as well.

I do agree that some requirements language could be derived to the effect
that a protocol supporting re-direct/referral MUST address this issue. I
think we probably disagree as to whether it (i.e. transitivity) applies
in the case of re-directed/referred DPV. (Well, I'm still not sure, rather
than claiming transitivity doesn't apply.)

> in a fashion invisible to end-user clients.

That sounds too close to protocol design, but something like that would 
probably be required when it did come to design-time.

Stephen.

---

From: "Housley, Russ" <[email-masked]>
Date: Tue, 09 Apr 2002 10:32:26 -0400

>   relay and/or re-direct (aka chaining and/or referral)

I could live with:

1.  The DPV protocol MUST NOT require DPV clients to support relay, 
re-direct or multicast.

2.  The DPV protocol MUST NOT prohibit DPV servers from employing relay 
(a.k.a. chaining).

I do not want to include any capability for re-direct (a.k.a. referral) for 
any party.

Russ