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: "Housley, Russ" <[email-masked]>
Date: Fri, 26 Apr 2002 09:58:57 -0400

>the natuer or reason of the request/response to appear in the

I think you are asking for an optional comment field.  Right?

>by the presidents of the congress and senate and by the members of

I do not think that such rules have anything to do with DPV and DPD.  We 
are not dealing with multi-party trust.  The client trusts the server that 
was queried.  The client does not care whether the server consulted other 
parties to come up with the response.

>   scope for the sole reason of not having been mentioned in this

I would not mind such a statement as long as it was explanatory (no 
MUST).  That is, a protocol that conforms to the requirements document can 
also meet other requirements so long as they are not in conflict with the 
ones in the requirement document.

Russ

---

From: Denis Pinkas <[email-masked]>
Date: Fri, 26 Apr 2002 16:43:19 +0200

Peter,

> the natuer or reason of the request/response to appear in the

The text from the client is blindly copied in the response. 

Your are now asking for a *new* requirement that has not been mentioned
earlier: the inclusion of an optional text field from the server.

We do not have such a feature in other protocols, like OCSP. There is also a
danger to apply different semantics on such a field. So I am not in favour
of adding it.

> by the presidents of the congress and senate and by the members of

Since you do not propose any specific text change, this text appears to be
sufficient and in fact is derived from your initial proposed wording. We
cannot argue for ever about the wording.

>   scope for the sole reason of not having been mentioned in this

I would disagree to place such a requirement. If the protocol would allow,
for example, to ask for flowers at the same time, :-), then I believed that
such a feature shall be suppressed.

This should place a final end to this large set of exchanged e-mails.

Denis