RE: SCVP 16 comments deadline

["Trevor Freeman" <trevorf@xxxxxxxxxxxxxxxxxxxxxx>]

* -----Original Message-----
* From: Peter Sylvester [mailto:Peter.Sylvester@xxxxxxxxxx]
* Sent: Friday, December 10, 2004 5:02 AM
* To: Peter.Sylvester@xxxxxxxxxx; Trevor Freeman
* Cc: ietf-pkix@xxxxxxx
* Subject: RE: SCVP 16 comments deadline
* 
* > [TF] How the server identifies the client is a mater of local server
* > policy.
* See my other message and a text proposal.
* 
* > *
* > * 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
* 
* None of these is a "declaration" of an identity. It is a means to
* authenticate
* the request at least in my opinion.
[TF] When I sign email, I don't include an additional attribute, I just
include my certificate. How is that not a declaration of identity.
* 
* Note the remark about 'may respond with an error' in
* the requirements. This is intended to mean that a server may reject
* a request when the declared entity is not one that can be
authenticated.
* (I don't think that it was meant that an error can be 'not
authorized')
* 
* >
* > 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.
* 
* Ok.
* 
* > *
* > * As already said in another may, this text could make sense if
there
* > * would be a corresponding requestorName in the request.
* 
* you seem to agree?