Subject: Re: Open issue: DPV relay

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

> 
> 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'd say this in a slightly slightly different way.  

A client MUST be able to authenticate the response at the moment when
he receives it. The authentication method should be as simple as possible.
Possible authentication methods include a signature (e.g. CMS
signedData), TLS/SSL authentication or evel lower layers.

Whenever there is a need that another entity needs to reverify
a response "later" (which may not be necessary in all
circumstances), an appropriate method to authenticate
the response MUST be available, i.e., a combination
of protocol data and services MUST be available to ensure
this feature.  

> I see no reason for the client to be made aware of an chaining or multicasting.
I'd say that the response MUST include all essential
element that have contributed to the decision, this MAY mean to
include some responses or the identities of entities that
have contributed to the response. 
 
> I do not think that we should include referrals in the DPV system at all.
I'm rather reluctant to have a referral type of mode, but Stephen Farrell
gave an interesting example that may be slightly modified as
follows:

 End user A  ask  server S1 "validate cert".
 S1 asks service S2. 
 S2 answers : Don't know, please go to service S3, here is a trustworthy cert of S3.
 S1 answers S3 
 S3 gives a signed response. 
 S1 validates the response agains the cert received by S3 and creates a final reponse
    to end user. 

I can imagine that there may be servers like S2 that would like to operate
that way.

---

From: "todd glassey" <[email-masked]>
Date: Mon, 8 Apr 2002 07:02:12 -0700

Isnt the question we are looking to address here  whether the DPV server can
prosecute the processing of a DPV request to a response or a next node in
that DPV server's or that Certificate's CHAIN OF TRUST.

So there are two issues really on the table here:

    1)    Does the Client have the ability to
            a)    Force the server to accept a particular chain of DPV
services to resolve its trusatability to the next DPV NODE as per the Client
            b)    Force the server to accept a particular chain of DPV
services to resolve its trusatability to the next DPV NODE as per the Server

    2)    Does the Server have the ability
            a)    To refer this request without the clients approval
            b)   Just Say No... That is "Sorry I cannot service this
request"...

T.