OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dss message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [dss] Observations on TST


Tim,

I do not think that we need to change the current meaning of time in that
the authority states tht the datum existing on or before the given time, and
that the time is to a given degree of accuracy.

I don't think that any change to this will do more than add confusion to
those using time-stamps.

Nick



> -----Original Message-----
> From: Tim Moses [mailto:tim.moses@entrust.com]
> Sent: 18 August 2003 21:25
> To: 'Trevor Perrin'; Nick Pope; 'DSS'
> Subject: RE: [dss] Observations on TST
>
>
> Colleagues - Another approach (that I quite like) is to include a
> time whose
> semantics are that the authority asserts that the particular configuration
> of bits existed on or before that time.  The authority would take its own
> accuracy into account in determining what time to assert.  I.e.
> it would add
> its own estimate of uncertainty to the time.  Then a client can
> simply rely
> on the fact that (according to the authority) the particular configuration
> of bits existed on or before the time it sees in the token.  What value is
> there in knowing that the authority may be wrong and that they could have
> existed earlier, by the amount of the uncertainty; the requestor
> might have
> held onto the bits for an amount of time that far exceeds the authority's
> uncertainty, before submitting them for timestamping.  All the best.  Tim.
>
> -----Original Message-----
> From: Trevor Perrin [mailto:trevp@trevp.net]
> Sent: Friday, August 15, 2003 2:57 PM
> To: Nick Pope; 'DSS'
> Subject: RE: [dss] Observations on TST
>
>
> At 09:32 AM 8/15/2003 +0100, Nick Pope wrote:
> > > Trevor wrote:
> > > One thing that worries me about the Accuracy field, as in RFC
> > > 3161 and the
> > > Entrust proposal, is that the client has to add and subtract the
> Accuracy
> > > field with the timestamp time to determine the upper and lower bounds.
> > >
> > > Isn't this non-trivial?  The client might have to know how many
> > > days are in
> > > each month, leap-years, leap-seconds, that sort of thing.
> > >
> > > Would it be easier for the server to explicitly return an upper and
> lower
> > > bound, instead of an Accuracy?
> > >
> >
> >I am not expecting that the upper and lower bounds is the main
> interest.  I
> >see accuracy as a quality indicator.  Changing to upper and lower bounds
> >make it much more difficult to decide whether the time-stamp is accurate
> >enough for my purposes.
>
> That's true.  I wonder if there's anyone with experience using
> RFC 3161 who
> can tell us how useful Accuracy is, and what it's most commonly used for.
>
> Trevor
>
>
> 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





[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]