RE: SCVP 16 comments deadline

[Peter Sylvester <Peter.Sylvester@xxxxxxxxxx>]

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

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.