Subject: Re: Open issue: requester identifier in DPV response

From: Peter Sylvester <[email-masked]>
Date: Fri, 26 Apr 2002 14:30:15 +0200 (MET DST)

> 
> So I am prepared to include two paragraphs:
> 
> The requestor MUST be able, upon request, to have a text field to be 
> copied in the response. As an example, this field may relate to the 
> nature or reason of the request/response.

I was thnking moire to a service like: 

The protocol MUST allow to provide to the requestor and/or the
responder a means to indicate a textual description indicating for example
the natuer or reason of the request/response to appear in the
result of the response. 

> When the request is authenticated, the requestor SHOULD be able, upon
> request, to indicate an identifier to be included in the response. 
> How this identifier is matched with the authenticated identity depends 
> on local server conditions and/or the validation policy. The server 
> MAY choose to refuse to include an identifier in the response, or MAY 
> refuse to create a response. 

There are

- IDs identifying the requesting entity (or entities) or
  entities which are entitled to use the response. 

- IDs identifying the responding or responsible entity (or entities)

I give an example (probably using the wrong rules). 

"We, the President of Unites States, and the General Secretary of
 the United Nation", certify to you, President of France, President
 of the French General assembly, and president of the French Senate,
 the the certificate XXYZ can be used by you as a strong authentication 
 method to demand deployment of a combined UN ad US forces on May 5 
 according to plan LEF". 

The request had been signed by two of three French authorities containg
the name of the persons involved and their roles. The response has
been signed by the two persons occupying the indicated 'role', plus
by the presidents of the congress and senate and by the members of
the UN security council.

> 
> This should close the last issue raised during the last call.
>

I propose that we add somewhere in the introduction a statement like: 

  A protocol feature proposal MUST not be rejected as out of
  scope for the sole reason of not having been mentioned in this 
  requirements document ".

---

From: "Tom Gindin" <[email-masked]>
Date: Tue, 16 Apr 2002 11:39:16 -0400

Denis, Peter:

      I have one question about this proposal.  Is the object to be placed
into the response a transaction identifier or the RP's identifier?  If it's
the RP's identifier, IMO it should be called something like "requestor's
claimed identity" and it should not be permitted to be altered by the
server, although it might be permitted to be dropped.

            Tom Gindin

Denis Pinkas <[email-masked]>@mail.imc.org on 04/16/2002 10:42:18 AM

Sent by:    [email-masked]

To:    Peter Sylvester <[email-masked]>
cc:    pkix <[email-masked]>
Subject:    Re: Open issue: requester identifier in DPV response

Peter and the list,

I have changed the name of the thread into "requester identifier in DPV
response" to reflect the issue.

I also believe that it is time to return to the list.

Peter is asking to add the following:

[The DPV server MAY require client authentication, therefore, the DPV
request MUST be able to be authenticated].

"When the request is authenticated, the requestor MUST be able, upon
request, to have an identifier to be included in the response. Whether
and how the communicated identification(s) are validated against identities
derived by some authentication method depends on local configurations.
Depending on that, the server MAY choose to copy, ignore, or replace
the identities by some other in the response, or to refuse the
request."

My personal opinion is that since the server policy (which has nothing to
do
with a validation policy) will be unkown (i.e. not visible in the response
and not fixed by the protocol), this field would have no value.

Opinions ?

Denis