RE: SCVP 16 comments deadline

["Trevor Freeman" <trevorf@xxxxxxxxxxxxxxxxxxxxxx>]

Hi Peter,
See below for answers
Trevor
* -----Original Message-----
* From: Peter Sylvester [mailto:Peter.Sylvester@xxxxxxxxxx]
* Sent: Monday, December 06, 2004 10:09 AM
* To: Trevor Freeman
* Cc: ietf-pkix@xxxxxxx
* Subject: Re: SCVP 16 comments deadline
* 
* 
* I am quite pleased that about the addition
* of requestorName in the responsea and that
* the convention of  consecutive null terminated
* strings in a requestorRef have been replaced,
* 
* But:
* 
* The syntax is GeneralNames. how many ids is the server intended
* to extract from a certificate? The subject + all alternate ids?
* 
* Why not having this id declared by the client, and the authentication
* methods matches against it. ==> Add a corresponding field in the
request.
* Which is required:
* 
*    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 DPV server MAY choose to blindly copy
the
*    identifier, omit the identifier, or return an error response.
* 
* It is an identifer identifying the client and not the request.
[TF] If the client sends a signed request with certificate it has
included a client identifier in the request. Its matter of local server
policy which name it chooses to return.
* 
* The new text replacing "requestor" in chapter 7 by "requestorRef".
* 
* > however,
* >  all of the octets MUST have values other than zero.
* Why? I would find it quite useful to add a
* hash of something local, if at all, the hash of its IP address for
example
* (for which I can use the Nonce as well).
[TF] If you want me to remove the clause about values being other than
zero - I am happy to do so. Since this is of local significance only, if
an implementation puts garbage in here it does not effect
interoperability.
* 
*   The requestRef item allows the client to associate a response with
*   a request.  The requestNonce provides an alternative mechanism ..
* 
*   and you have also the requestorRef.
* 
* The concept of trying to make loop control with values which are
* explicitely
* defined as not globally unique sounds strange to me.
[TF] I have a big problem which the concept of global uniqueness. I
class it the same bucket as non-repudiation. 
* 
*  "The requestorRef item is also needed
*   to prevent looping in some configurations"
* 
*  "No provisions are
*   made to ensure uniqueness of the requestorRef octet string"
* 
* The usefulness of "requestorRef" as an identifier for the request
* is pretty weak, since you can have a nonce if it is for each
* request. use GeneralName(s) in a requestorName sequence as for the
* response.
* 
* page 34:
* 
*   The requestorRef and the responder items MUST be included if the
request
* included a
*   requestor item.
* 
* what does this mean? what is the relationship between a requesterRef
and
* responder?
[TF] If requestorRef is populated, it means it's a relayed request in
which case the responder is of significance.
* 
* If I'd be interested in anything identifying the response, then it is
* a sequence of identifiers of the servers that have partipated, and
some
* local ids or "serial number' like thing if I want to go to that server
and
* asks 'did you really tell this to my friend'.
* 
* 
* Chapter 7: Denis is right that the spec does not describe how relaying
is
* performed, i.e. how a response is created from a response received
from
* another
* server by a 'proxy'.
[TF] What specifically are you looking for?
* 
* 
* 
* 
*