RE: SCVP 16 comments deadline

[Peter Sylvester <Peter.Sylvester@xxxxxxxxxx>]

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

Are you saying that this client identifier is the "issuerSerial"?
What field *IS* the "client identifier"? The certificate is not
a client identifier? In a certificate, you may have several identifiers
concerning the entity. 

The client has no way to set an "identifier for itself" in the request, so that 

   "the DPV server MAY choose to blindly copy the identifier".

The server that you propose ALWAYS MUST create some generalnames
structure for which no guideline is given on how it could be
derived from the requestorRef which is an item that has no relation
at all to the returned requesterName. 

Since two years or so I am asking that you just make two elements

requestor GeneralNames
responder GeneralNames

in both the request and the response. (and to get rid of the octet string stuff)

I may have not understod your intention of "responder", if this is a pure
local reference of the RESPONSE vs the repspoinder, then I think a 
sequence number would be more appropriate. 

> * 
> * 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.
How do relate 'local significance only' and the usage of such fields
for 'loop control'. The significance not just local. 
If relays just put "relay" as a local reference you will have problems. 

LOOONG time ago, I told you that an encoding of identifiers in an octet string
sounds strange, given that we have lots of ways and that you don't provide
any guideline on how identifiers can be encoded.

Although you violantly rejected all proprosals to change this, you
silently starting doing this in this version:

- replacing an octet string by a sequence  (good, but omitted the only reason
  for not allowing zeros).
- adding a requesterName item with is a generalnames
  

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

You are operating in a PKI where ID's of
entities are unique within the PKI. If you don't trust the
naming rule in your PKI, i.e. in some associated SCVP network
which is much smaller, i.e. in the magnitude of the size of
the CA name space.

Well, domain names work as far as I know. And telephone numbers also.
I don't say that non-repudiation doesn't work. I don't say that
I agree or disagree with your comparision since I do not see why this
is relevant here. 

You are not even answering the question: You make loop control, and
you explicitely says that the identifiers that are used do only have
local significance. You could have said: An example for identifiers
that could be used for loop control are uuids generated on each server
startup using the server address and a time value. 


> * 
> *  "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.

No. any client can set a requestorRef, independant of whether the request
will be relayed. What is the significance of responder? In your spec
it is only of local signifance for the responding server? waht can this
be good for? 

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

A working specification that includes:

- how a request received is transformed into a new request by a relay,
  which fields are copied, or not, or may.
- how the response is transformed into a response to the original request
  there are SEVERAL options, in particulat the one that addresses
  the requirement of allowing a response as part of another one.