Re: SCVP 16 comments deadline

[Peter Sylvester <Peter.Sylvester@xxxxxxxxxx>]

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. 

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).  

  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.

 "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?  

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'.