RE: Serving static responses

The RequestID was put in to provide a lightweight mechanism that allows
clients to determine that the response corresponds to their request.

It is not a particularly strong mechanism, in particular it is not at
all secure if the request is not authenticated which is why we have
introduced the strong binding to the request by means of the request
signature repeater.

Having added in a strong mechanism I think we should probably consider
removing the weak mechanism even if it did not cause problems. Since
this mechanism is going to cause serious problems for the static signer
case we should remove it.


Incidentally there are cases where one would want to do static signer
for security reasons. For example consider the case where we have an
online key and an offline key that are used to create an authentication
chain for the XKMS service. We would probably want to generate the XKMS
response that validates the cert of the online key using the offline key
from the vault on a quarterly basis. We certainly would not want to and
obviously could not put the offline key online...


		Phill



> -----Original Message-----
> From: Joseph Reagle [mailto:reagle@w3.org]
> Sent: Tuesday, February 04, 2003 1:51 PM
> To: Hallam-Baker, Phillip; stephen.farrell@baltimore.ie
> Cc: www-xkms@w3.org
> Subject: Re: Serving static responses
> 
> 
> On Tuesday 04 February 2003 12:52, Hallam-Baker, Phillip wrote:
> > As a minimum RequestID becomes optional. Otherwise 
> RequestID is in the
> > context that is signed and so the response has to be 
> dynamic - which is
> > not suprising since that it the whole point of RequestID
> 
> Do those with better memory remember why we made it required 
> in the first 
> place? Was it satisfying some requirement with respect to security or 
> correspondence within the asynchronous/multi-stage query/response?
>