RE: SCVP 16 comments deadline

["Trevor Freeman" <trevorf@xxxxxxxxxxxxxxxxxxxxxx>]

Hi Peter,
* -----Original Message-----
* From: Peter Sylvester [mailto:Peter.Sylvester@xxxxxxxxxx]
* Sent: Tuesday, December 07, 2004 4:15 AM
* To: Trevor Freeman
* Cc: ietf-pkix@xxxxxxx
* Subject: Re: SCVP 16 comments deadline
* 
* To have an independant issue:
* 
* 
* 4.8 requestorName
* 
*   The optional requestorName item is used by the server with signed
*   requests to return the identity of the client in the response.
*   Mechanisms for matching this identifier with the authenticated
*   identity are a matter of local server policy.
* 
*   In the case of non-cached responses to signed requests, the SCVP
*   server MUST return a requestor name.  A server SHOULD copy the
*   selected identifier from a certificate or other credential used to
*   authenticate the request.  A SCVP server MAY use a client
*   identifier from an out-of-band mechanism or omit the identifier
*   from the response.
* 
*   In the case of cached responses to signed requests, the
*   RequestorName MAY be present in the response.
* 
*   SCVP server that supports signed requests MUST support this item.
* 
* This chapter is new and pretty uncomprehensible:
* 
* "matching" is IMO an action where you have two inputs, I don't see
* where the identifier comes from, or when it is extracted from
* some authenticated information, why there is a "matching" at all.
* "The identity" of the client is not defined anywhere in the document.
[TF] How the server identifies the client is a mater of local server
policy.
* 
* The 3379 text says:
* 
*    When the DPV request is authenticated, the client SHOULD be able to
*    include a client identifier in the request for the DPV server to
copy
*    into the response.  Mechanisms for matching this identifier with
the
*    authenticated identity depends on local DPV server conditions
and/or
*    the validation policy.
* 
* The client has no way to declare its identity in the protocol,
* and there no provision of what this could be from what it would
* be derived from (IP address, DNS name of the host, ...), ...
[TF] The client can declare its identity in the request in a number of
ways.
 	1. by including its signing certificate in the request
	2. by including its DH certificate used to compute the hmac
	3. By HMACing the request using a shared secret or password

What identity the server knows or uses for the client based on this data
is a matter of local server policy
 
* 
* Why is this restricted to signed requests, and not to 'authenticated'?
[TF] Its not. Section 3 defies signed requests as being either
signedData or authenticatedData.
* 
* As already said in another may, this text could make sense if there
* would be a corresponding requestorName in the request.
* 
* 
* 


Trevor