Subject: Re: I-D ACTION:draft-ietf-pkix-dpv-dpd-req-03.txt

From: Peter Sylvester <[email-masked]>
Date: Tue, 2 Apr 2002 20:00:03 +0200 (MET DST)

> 
> COMMENT 7: Requests shall be able to be authenticated.

At the end of the following exchange you mention that it
is unclear what requirement is being addressed and
what ind of treatment would be done with such an identity
field. The comment is not necessarily related to 
authentication. 

- The requirement is to include the identities of 
  participating parties in the request and in the 
  response, in order to indicate who has participated.

  This is independant of whether this matches with
  some authentication. 

- The treatment is essentially for display purposes
  to be able to describe show the transaction result
  together with the identities with the need to 
  understand a particular way how these information
  can be found in some authnetication envelope.

- Anyway, the response should provide for a means
  to indicate for whom the response has been made,
  not only who has made the response.  
   
Peter

----------------------

[About COMMENT 7]

> - a method that client and server provide their identity
>    in the requests and responses: 'You, the client X, has
>    asked me, the server Y, the following question, and
>    I, the server Y, with the help of server Z respond.'

> This allows to be able to determine the participating entities
> without having access to whatever particular authentication
> method information.

> [Answer 7] Actually, we already include the identity of the server in the
> response. The request could also be optionally signed. This allows 
> the server to authenticate the client, and this authentication allows the 
> server to only support a selective community if desired. An option to be
> able to sign the request may be added.

> The following requirements may be used for example in case of
> validation of an encryption certificate before usage.

There is a difference between authentication and identification.
The request is that the identification is independant from the
authentication methods and the transports. 

A signing entity (the one identified in a signer info or a certificate)
may or may not be the same as the one declared in the request/response.
you may have separation of roles or other situations. 

"The President of the United States declares, ... signed by JWB".

Another example is in relaying as follows: 

Your company service declares that I can use Your encryption cert,
and the response is signed by my local service. 

[Additional Answer 7]

It is unclear what requirement is being addressed and what kind of treatment
would be done with such an identity field.

---

From: "Housley, Russ" <[email-masked]>
Date: Wed, 03 Apr 2002 09:32:19 -0500

Peter:

Would you be happy if the client and server identities were optional?

Russ

---

From: Denis Pinkas <[email-masked]>
Date: Wed, 03 Apr 2002 17:14:16 +0200

Peter,

>   response, in order to indicate who has participated.

It is proposed to add after the current last paragraph from section 4: 

"When the request is authenticated, the requestor shall have the possibility
to have its identifier included or not in the response."

>   not only who has made the response.

Since relaying is not supported (see the response to your other e-mail),
there is no difference between "for whom the response has been made" and
"who has made the response".

Denis