RE: SCVP 16 comments deadline

["Trevor Freeman" <trevorf@xxxxxxxxxxxxxxxxxxxxxx>]

Hi Peter

* -----Original Message-----
* From: Peter Sylvester [mailto:Peter.Sylvester@xxxxxxxxxx]
* Sent: Thursday, December 09, 2004 3:47 AM
* To: Peter.Sylvester@xxxxxxxxxx; Trevor Freeman
* Cc: ietf-pkix@xxxxxxx
* Subject: RE: SCVP 16 comments deadline
* 
* > *
* > * 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"?
[TF] I am saying how the server identifies the client for the supplied
information is a matter of local policy to the server.
* What field *IS* the "client identifier"? The certificate is not
* a client identifier? In a certificate, you may have several
identifiers
* concerning the entity.
[TF] I am saying how the server identifies the client for the supplied
information is a matter of local policy to the server.
* 
* 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.
[TF] I am saying how the server identifies the client for the supplied
information is a matter of local policy to the server.
* 
* 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.
[TF] Names give by an instance of a PKI are by definition not global.
* 
* 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.
[TF] Are you asking a question or suggesting text for the draft? If you
want an example of how one might generate a identifier of local
significance I can do that.
* 
* 
* > *
* > *  "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?
[TF] It good for detecting loops. The server adds an identifier which it
recognizes to the response. It is the only one rrequired to recognize
the value so it can put whatever it wants in the field. There is no need
to standardize the behavior of the SCVP server in this regard.
* 
* > *
* > * 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.
[TF] OK. I will add that.

Trevor
*