RE: SCVP 16 comments deadline

["Trevor Freeman" <trevorf@xxxxxxxxxxxxxxxxxxxxxx>]

Peter

* -----Original Message-----
* From: Peter Sylvester [mailto:Peter.Sylvester@xxxxxxxxxx]
* Sent: Friday, December 10, 2004 5:01 AM
* To: Peter.Sylvester@xxxxxxxxxx; Trevor Freeman
* Cc: ietf-pkix@xxxxxxx
* Subject: RE: SCVP 16 comments deadline
* 
* > [TF] I am saying how the server identifies the client for the
supplied
* > information is a matter of local policy to the server.
* 
* Repeating this three time doesn't make the statement true. It is
* totally contrary to what is described in the requirements document.
* 
*    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.
[TF] 
Reputedly copying the same section from 3379 has the same effect. I
believe the current draft of SCVP complies with the text. The name must
be in the certificate. I don't see value in repeating the value twice in
the request.

* 
* If you don't agree about the meaning of 'client identifier' in the
* following excerpt, then we will not be able to get anywhere further.
* 
* If the intention of the excerpt above would be that the client does
not
* explicitely do provide an identifier, then the text would be like:
* 
*    When the DPV requets is authenticated, then server MAY return to
the
*    client an identifier derived from the authentication.
* 
* if you want to derive *one* identifier from the authentication, what
will
* you set for a certificate with one or more instances of
subjectAltname.
* The best you can do is to return all identities.
* 
* The client has to have a means to explicitely present his identity.
* 
* This is an identifier where the client declares its identity,
furthermore
* this identifier being an octet string without any structure is not
* something that is common in PKI environments, in particular you
already
* return a GeneralNames structure in the requesterName.
* 
* I simply repeat my request to add requesterName and a responderName
* structure
* in both the request and the response.
* 
* here a text proposal:
* 
* x.x.x Entity identification.
* 
* Since an SCVP response MAY be used by a client to demonstrate to
another
* relying party that certificate validation has been duly performed, the
* protocol allows to add identities of requesting clients and responding
* server to the response.
* 
* An identity is encoded as GeneralName. (cf. syntax)
* 
* Servers may have more than one identity, for example, a URI
* to access to the service, or a DN related or not to CAs.
* In particular, an SCVP server may have the same identity as a CA
* for which the server can provide answers in a similar way as an
* OCSP server.
* 
* The protocol is as follows:
* 
* x.x.x.1 requesterName
* 
* This field in the request indicates one or more identities
participating
* in the creation of the request. A client MAY add this field to a
request.
* If the request is authenticated, one of the presented identities
SHOULD
* match with at least one identity that can be derived from
authentication.
* A server MAY accept a request even if the presented identities do not
* correspond to one derived from authentication. If the request cannot
be
* authenticated, a server SHOULD reject the request if it contains this
* field.
* 
* On relaying, a relay MAY choose not to copy the presented identity to
* the relayed request, e.g., to anonymize the requester.
* 
* This field SHOULD be returned as is in the response. A server MAY
choose
* to add additional identities. This may be done when a relay is
involved,
* when an authenticated identity is different.
* 
* (merge some stuff from the existing requesterName if necessary).
* 
* x.x.x.1 responderName
* 
* This field in the request indicated identities of one or more servers
that
* are intending to participate in the construction of the response. This
* may be used for example to indicate to a relaying proxy the identity
of
* another scvp server.
* 
* This field in the response indicate the identities of the servers that
* have participated in creating the response. There is no particular
* relationship with the field with the same name in the input.
* 
* ------
* 
* Now we can treat the usefulness of the requester/responder for,loop
* control independantly.
* 
* > *
* > * 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.
* > *
* 
* what is the current definition of responder good for? You menton
something
* below, see later.
* 
* 
* > * > *
* > * > * 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
* > *
* > *
* 
* I probably expected some [TF] here, but well, you seem to agree.
* 
* > * > *
* > * > *   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.
* 
* Can you point me to the definition?
* You may have a problem of ensuring uniqueness of name inside the PKI
* this but that's a similar proble as for the domain name system,
* it is organisational and not technical.
* Names inside a PKI are non-ambiguously associated to the
* entities as far as I remember.
* 
* I really don't see what you are arguing about?
* 
* > *
* > * 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.
* 
* An identifier of 'local' significance is simple: 'I'
* 
* It seems that we don't agree about the meaning of 'local
significance'.
* 
* You need that each potentially participating entity has at least one
* identifier which are distincet among the servers, but may or not
* have any global 'significance'.
* 
* If you want to keep the requester item for this, why not. it may be
* useful not to overload an 'identification', a nonce, a loop control
* tickmark
* in the same field.
* 
* > * > *  "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.
* 
* To be sure: The question was: "What is the significance of responder?"
* How does this value occur in the loop control algo? So far, the server
* just adds this, and noone is doing somthing with it, at least not in
* the current spec?
* 
* > *
* > * > *
* > * > * 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.
* good.
* 
* Would it be possible to send a draft to the list before it get graved
into
* electronic marble.