UploadResponse and LastModified [Was: Re: [Fwd: I-D ACTION:draft-ietf-sacred-protocol-bss-03.txt]]

Stephen, All,

Reopening this discussion... As I have argued before, without an
<UploadResponse> message containing a <LastModified> element, the
following may occur:

a) Client uploads a credential using LastModified as given by server
   in response to a <DownLoadRequest>.

b) Server stores new credential, assigns a new <LastModified> value.

c) Client modifies the credential, sends new <UploadRequest> but
   (must) use the original <LastModified> element value.

d) Server rejects upload since <LastModified> provided by client does
   not match that in the server database and hence server gets the
   impression that client made a modification to credentials that were
   not up-to-date.

I therefore propose that an <UploadResponse> message is created, which
carries the new <LastModified> value for the client. Use cases for
this includes a client which generates a private key and sends a
certificate request, uploads while waiting for the certificate to be
issued and then uploads again when the certificate has been received.

An alternative is to require (or recommend) clients to do a
<DownloadRequest> before starting to modify a credential, even if they
just made an upload, but this would then have to be mentioned explicitly
in the document to avoid this error situation.

In addition, the text in Section 2.2.1: "the client SHOULD include its
best idea of the LastModified value in the credential" is wrong. A
"best idea" does not help the server at all in determining whether an
uploaded credential was based on an up-to-date copy of the credential
in the server's store or not. The client MUST include the LastModified
value as provided by the server in the <DownloadResponse> message that
carried the credential.

-- Magnus