Re: SCVP 16 comments deadline

[Peter Sylvester <Peter.Sylvester@xxxxxxxxxx>]

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.

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

Why is this restricted to signed requests, and not to 'authenticated'?

As already said in another may, this text could make sense if there
would be a corresponding requestorName in the request.