RE: [dss] t+/-dt

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

Tim, see below:

> -----Original Message-----
> From: Tim Moses [mailto:tim.moses@entrust.com]
> Sent: 26 August 2003 18:07
> To: 'Nick Pope'; Tim Moses; 'DSS'
> Subject: RE: [dss] t+/-dt
>
>
> Colleagues - Two questions, then ...
>
> 1. Do we expect relying parties to use the "accuracy" indication
> purely and
> simply to evaluate the quality of the service, or do we expect them to use
> it to calculate the most conservative estimate of time?
>
I expect the former - indication of accuracy.


> 2. If the former, then, is putting this information in each timestamp the
> right approach, or should it simply be a mandatory component of the
> service's policy?

Generally I would expect this to be part of the policy, although I see the
content of service policy out of our scope so we cannot mandate it.  It is
only if the accuracy of the time-stamp is dynamic (e.g. due to change in
sychronisation source) would this be of relevance.

> There are (after all) many components of quality,
> including which source of time the service uses (e.g. which national time
> standard), and we are not proposing to include this information explicitly
> in each timestamp.  Do we expect authorities to continually evaluate their
> own accuracy and adjust the accuracy indicator accordingly?
>
> I don't see the relevance of the "network delay" argument.  Naturally, an
> authority can only make assertions about information it has fully
> received.
> We should not expect it to speculate about what might have happened
> beforehand.  This is an inevitable (and hopefully acceptable)
> consequence of
> our architecture.
>
> I could certainly live with a model in which relying parties always add or
> subtract a delta from the asserted time and only recognize authorities or
> timestamps whose accuracy value is less than that delta.

I am not sure about the use of the "most concervative time".
>
> All the best.  Tim.
>
> PS.  The final paragraph suggests we should call the indicator "estimated
> error", rather than "accuracy".
>
> -----Original Message-----
> From: Nick Pope [mailto:pope@secstan.com]
> Sent: Tuesday, August 26, 2003 10:02 AM
> To: Tim Moses; 'DSS'
> Subject: RE: [dss] t+/-dt
>
>
> 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_wor
> kgroup.php
>
>
>
>
>
> You may leave a Technical Committee at any time by visiting
> http://www.oasis-open.org/apps/org/workgroup/dss/members/leave_wor
> kgroup.php
>
> You may leave a Technical Committee at any time by visiting
http://www.oasis-open.org/apps/org/workgroup/dss/members/leave_workgroup.php