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

This is another one where we disagree, but is more substantive
than the editorial stuff in the other messages (and so help from 
the list is needed!).

I'd rather stick with not requiring an UploadResponse and
will put the new recommendation you suggest below (that 
modify's be preceeed by downloads) into my working draft 
for the present. 

My reasoning is that I don't see these use cases as being
common (how often do you modify credentials? not often, how
often do you do it twice in succession? never.) and
they aren't afaik reflected in the requirements rfc and
I prefer the minimal change rather than introducing a new
message.

Stephen.


"Nystrom, Magnus" wrote:
> 
> 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.

I put a "strongly RECOMMEND" version of this into my working draft
for the present.

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

Yep. Will do.

> 
> -- Magnus

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) +353 1 881 6716
39 Parkgate Street,                     fax: +353 1 881 7000
Dublin 8.                mailto:[email protected]
Ireland                             http://www.baltimore.com