RE: [dss] t+/-dt

["Nick Pope" <pope@secstan.com>]

Tim et all on DSS

As I mentioned on yesterdays conference call my view is that bringing in two
times add a whole new set of complexities to applications in deciding which
time is relevant.  If the difference in the two possible time becomes
significant to an application then other factors, such as network delay,
come into play.  Accuracy gives a simple indication of the quality of the
time-source and provided that this is within an level that is not
significant to an application then the diffence between the t+dt and t-dt is
not significant.  If this is of significance then other factors which effect
the accuracy (e.g. variance in network delay) also need to be taken into
account.

Nick

> -----Original Message-----
> From: Tim Moses [mailto:tim.moses@entrust.com]
> Sent: 25 August 2003 21:10
> To: 'DSS'
> Subject: [dss] t+/-dt
>
>
> Colleagues - There are two common ways of expressing the time
> when there is
> a degree of uncertainty.
>
> 1. a=t+dt, b=t-dt, or
> 2. a=t, b=dt
>
> Of course, one can readily convert values between the two styles.
>
> I can think of a couple of reasons for choosing style 2.  The
> first is that
> paradoxical statements cannot be made in style 2 (one cannot say before
> 2:00pm on Friday, but after 2:30pm on Friday).  The other is that
> style 2 is
> more compact, or stated differently, in most cases, the year, month, date,
> hour, minute and time-zone offset values in t+dt and t-dt will be
> identical.
>
> But, it seems to me that the most appropriate way to choose
> between the two
> styles is to consider whether the client or the server should bear the
> computational burden in the most common applications.  In keeping with the
> philosophy of the architecture (simplifying matters for the
> client) it seems
> apparent that any computational burden should fall on the server.
>
> Except in cases where the client is not concerned about the accuracy, I
> cannot think of an application in which the client is interested
> separately
> in the server's estimate of the time and its estimate of the
> uncertainty in
> that time.
>
> Some of the most common situation are where the relying party
> wants to know
> definitively whether t is earlier or later than some t'.  In the former
> case, it should compare t' with t+dt and in the latter case, it should
> compare t' with t-dt.
>
> Here are some examples where the relying party compares times:
>
> - Determining if a signed document was created within the
> validity interval
> of a private key.
> - Determining if a signed document was created before a certificate was
> revoked.
> - Determining whether a bank deposit was made before a withdrawal.
>
> There are also situations in which the relying-party wants to know
> definitively the earliest or latest time at which a certain event
> could have
> occurred (e.g. creation of a document).  In the former case the relying
> party is interested in t+dt and in the latter case in t-dt.
>
> If the relying-party is not concerned about accuracy, then there it can
> simply choose to use t-dt or t+dt, in place of t.  We could make it
> mandatory to include t+dt in a timestamp token and optional to
> include t-dt.
>
> It has been argued that style 2 is more conventional or intuitive; it is
> more consistent with a service that simply asserts that it performed a
> certain action at a certain time, regardless of how one might use that
> information in a given business context.  Personally, I don't find that
> argument persuasive.
>
> What do others think?  All the best.  Tim.
>
>
> -----------------------------------------------------------------
> Tim Moses
> 613.270.3183
>
> You may leave a Technical Committee at any time by visiting
http://www.oasis-open.org/apps/org/workgroup/dss/members/leave_workgroup.php