Re: LastModified [was: Re: I-D ACTION:draft-ietf-sacred-protocol-bss-01.txt]

[Stephen Farrell <stephen.farrell@xxxxxxxxxxxx>]

Gareth,

Not sure which way we should go on this one (anyone else?). Agree
that not depending on a client clock is good though.

If we do take this approach then I'd probably want to take the 
LastModified from the inner sequence of credential structure just 
in case someone sometime wants to e.g. sign our credential 
structure (the problem of course would  be that the server 
would be modifying, making xml signing harder to do).

Shouldn't be a problem to do that, just means having separate 
"inner" & "outer" structures maybe (partly including an earlier 
change) like:

    <complexType name="CredentialsType">
      <sequence>
        <element name="LatestLastModified" type="dateTime"/>
        <element name="Creds" type="sacred:OuterCredentialType"
           maxOccurs="10" /> <!-- I *may* only be kidding about this:-) -->
      </sequence>
    </complexType>
	
    <complexType name="OuterCredentialType">
      <sequence>
        <element name="LastModified" type="dateTime"/>
	<element name="Cred" type="sacred:InnerCredentialType" />
      </sequence>
    </complexType>

     <complexType name="InnerCredentialType">
       <sequence>
         <element name="CredentialSelector" type="string" />
         <element name="Payload" type="ds:KeyInfoType"/>
         <element name="TimeToLive" type="string" minOccurs="0"/>
         <element ref="sacred:ProcessInfo" minOccurs="0"/>
         <element ref="sacred:ClientInfo" minOccurs="0"/>
       </sequence>
     </complexType>

Questions:-

- other suggestions?
- any point in both LatestLastModified and LastModified?

Stephen.

Gareth Richards wrote:
> 
> Stephen,
> 
> Section 3.10 of draft-ietf-sacred-protocol-bss-01.txt describes the use of
> the LastModified and PrevLastModified values in UploadRequest.
> 
> I am concerned that there may be a potential for problems if we rely on the
> clients to set this time when they may have inaccurate clocks.  It does not
> appear as if there is a problem in detecting conflicts during upload since
> the actual value of LastModified is not important (the server can treat it
> as an opaque blob) but there may be potential problems on the client.
> 
> If a user did the following
> 
> Download to platform A, update from A, download to platform B
> 
> then there could be some confusion if the clock on platform A was ahead of
> that on platform B.  The user could be told that "your credentials were
> last modified tomorrow".
> 
> The same section states
> 
>    Note: A server SHOULD ensure that the LastModified value in the new
>    credential is reasonably accurate. If it isn't then the server
>    SHOULD respond with an error message in which case, the server MUST
>    NOT store the new credential.
> 
> This seems to imply that it will only be possible for clients with clocks
> in close agreement with the server to upload credentials.  It therefore
> seems as if it would be safer to have a LastUploaded time maintained by the
> server.
> 
> I therefore suggest that PrevLastModified be removed.
> 
> Section 3.2
> 
> Second item be replaced with
> 
>    - LastModified specifies the time at which this credential was last
>      changed on the server.
> 
> Section 3.10
> 
> Remove first two paragraphs and replace PrevLastModifed with LastModifed in
> second two.

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