Subject: Re: Open issue: requester identifier in DPV response

From: "Housley, Russ" <[email-masked]>
Date: Wed, 01 May 2002 08:16:38 -0400

Peter:

> > > - This text may be created by the server or requested by the client
> > >   or modified by the server.
> >
> > No. See above.
>
>Thus, you are restricting a potential protocol feature. If a proposal
>will allow a client to propose a text, you would consider this
>as in conflict with the requirements doc?
>
> >
> > > I am not in favour that the usages of identififers of the clients
> > > and responders MUST be related to authentication.
> >
> >  ... otherwise it is a field that has an undefined or an ambiguous
> > semantics.
>Russ and you have proposed that the ID are derived from authenticated
>identifiers, it seems that the main difference is that I prefer that
>they are matched against information from authentication.
>
>You propose:
>   "When the request is authenticated, the requestor SHOULD be able, upon
>   request, to indicate an identifier to be included in the response.
>
>What does mean 'SHOULD be able'?  We are talking about requirements for
>a protocol. Either the protocol has a feature that can be optionally be
>used or it hasn't.

It means that a protocol that conforms to these requirements SHOULD include 
this feature.  It still conforms if it does not include this feature.  In 
other words, I do not think that a protocol that does not include this 
feature is unsuitable.

>Why should even an anonymous requester not be allowed to specify an 
>identifier?
>As indicated in the followng sentence, a server can always refuse this
>nased on the policy etc.
>
>   How this identifier is matched with the authenticated identity depends
>   on local server conditions and/or the validation policy. The server
>   MAY choose to refuse to include an identifier in the response, or MAY
>   refuse to create a response."

Doesn't the nonce fulfill this need?

Russ

---

From: Peter Sylvester <[email-masked]>
Date: Fri, 3 May 2002 11:31:37 +0200 (MET DST)

> other words, I do not think that a protocol that does not include this 

So we are here at a point of discussing whether we can afford to create
a protocol feature which essentially allows a client to specify a data
element of the complexity of let's say GeneralNames in its request,
and to have a server to just copy it to the response, to ignore this,
or to create its own one, all this optionally based on a policy.

I would agree with you that a protocol SHOULD implement optional features,
so that in some really 'small' environments one can still have a conformant
implementation. 

What are some possible sitiuations: The 'small' environment is probably
the 'client' side. Thus: A client may not send identifiers to the server.
That's not a problem for the server. 

It may happen that by some policy, a server always returns the identification 
of the client (derived by some means) and his own. 
if the client does not understand the response, one may consider this
as a configuration error in the server. 
 
> Doesn't the nonce fulfill this need?
The purpose of requester and server identifiers is to identify 
the requesters and the responders matched in some way against 
the data that are part of the authentication method. Also, after
receiving the response, you can throw away all authentication
data because they do not contain necessary information concerning
the statement made by the server. 

As far as I understand, nonce are only there to provide some
mechanism for replay protection in particular contexts. Overloading
nonces by puting some more or less defined meaning to the content
doesn't seem to me a desirable approach. 

Peter