Subject: RE: Open issue: DPV relay

From: "Trevor Freeman" <[email-masked]>
Date: Mon, 8 Apr 2002 18:48:33 -0700

Asking for a DPV relay is serious miss-interpreting the intent of DPV. 

In DPV you have a security association between the client and DPV
server. The client is outsourcing its certificate trust decisions to DPV
server. It is reasonable for the DPV server to employ any resource it
deems necessary to complete the request from the client that the DPV
server underwrites. The DPV server has to decide what resources it uses.
None of this is of any consequence to the client as long as the decision
is gives back to the client in accordance with the previously agreed
policy. All the client wants is a decision according to the policy. A
client could set up multiple SA to different DPV servers if it wanted
higher assurance that the answer from the DPV server was the "right"
answer - but that begs the question of why the client is not using DPD

Trevor

-----Original Message-----
From: Housley, Russ [mailto:[email-masked]] 
Sent: Monday, April 08, 2002 9:22 AM
To: Peter Williams
Cc: [email-masked]
Subject: RE: Open issue: DPV relay

Peter:

I think you are changing the context of my statement.  I said: "... 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 did not say that the client could not have a trust relationship with
more 
than one DPV server.

Russ

At 05:28 PM 4/5/2002 -0800, Peter Williams wrote:

>Todd,
>
>I do not believe we should formulate any
>particular use-model at this time, for DPV REQUIREMENTS;
>leaving aside the philosophical issue of
>whether use-modeling would or would not help IETF standards
>adoption. The requirements should prepare for
>protocol-specification, not establish operational
>usage constraints.
>
>The only valuable use-issues topics I can forsee that might
>serve us (in contradiction to the above) are precisely
>those that Ambarish mentioned: do what OCSP did,
>so succesfully in the Internet environment... for the
>same issue; and dont lets sucumb to the temptation to
>over-architect!
>
>--------------
>
>In my view, on Russ side comment, constraining DPV to
>require users to interact
>with a service provider at a single access-point is
>like setting the clock back on X.509, and requiring
>the world to adopt the Entrust use-model
>of PKC key management. Entrust's use-model makes
>for a fine and highly-manageable system, but it
>competes (successfully) with other domain-management
>models that are equally succesful in the wider Internet
>environment we server.
>
>The only trust issue for DPV requirments I can see
>is this:
>
>Just, as Sharon recently indicated, PMI's SOAs
>are trusted as authoritative for their policy
>scope, so DPV servers are trusted. PMI deals
>with privileges; DPV deals with remote processing
>of chains against validation policies. The two
>authority models are really identical, otherwise.
>
>Lets note that PMI didnt constrain an AC verifier to use
>only a single SOA-headed source of AC paths. So
>should the DPV requirements not constrain the
>DPV client from accepting results from
>any  set of (possibly (out of IETF scope) constained) DPV
>servers - whose service is provided at the
>access point to which the client is bound (including
>that operated, perhaps, by a simple-proxing or a
>chaining&resigning DPV server).
>
>
>-----Original Message-----
>From: todd glassey [mailto:[email-masked]]
>Sent: Friday, April 05, 2002 3:52 PM
>To: Housley, Russ; jim
>Cc: [email-masked]; Tim Polk; [email-masked]
>Subject: Re: Open issue: DPV relay
>
>
>
>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
>
>
> >
> > 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.
>
>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: "Santosh Chokhani" <[email-masked]>
Date: Tue, 9 Apr 2002 08:16:09 -0400

All:

I agree with what Trevor says.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Trevor Freeman
Sent: Monday, April 08, 2002 9:49 PM
To: Housley, Russ; Peter Williams
Cc: [email-masked]
Subject: RE: Open issue: DPV relay

Trevor

-----Original Message-----
From: Housley, Russ [mailto:[email-masked]] 
Sent: Monday, April 08, 2002 9:22 AM
To: Peter Williams
Cc: [email-masked]
Subject: RE: Open issue: DPV relay

Peter:

Russ

At 05:28 PM 4/5/2002 -0800, Peter Williams wrote:

>particular use-model at this time, for DPV REQUIREMENTS; leaving aside 
>the philosophical issue of whether use-modeling would or would not help

>IETF standards adoption. The requirements should prepare for
>The only valuable use-issues topics I can forsee that might serve us 
>(in contradiction to the above) are precisely those that Ambarish 
>mentioned: do what OCSP did, so succesfully in the Internet 
>environment... for the same issue; and dont lets sucumb to the 
>temptation to over-architect!
>
>--------------
>
>models that are equally succesful in the wider Internet environment we 
>server.
>
>any  set of (possibly (out of IETF scope) constained) DPV servers - 
>whose service is provided at the access point to which the client is 
>bound (including that operated, perhaps, by a simple-proxing or a
more
about
perform an
or it
all.
between
agreement
sources
stand
client
need
trust
someone
next
request
agent is
willing

information
to