Subject: Re: New TSTTime definition

From: Peter Sylvester <[email-masked]>
Date: Thu, 5 Aug 1999 11:29:38 +0200 (MET DST)

> 
> Decimal conversion is very easily accomplished.  Slightly more
> difficult (but still easy) is conversion to calendric form if a
> pure seconds count is utilized.  However, one of the things that
> one might wish to do with timestamps is compare times -- either
> two timestamps, or a timestamp's time with a fixed calendric date.
Decimal conversion is not that easy. If one uses a certain
precision of the binary, and if you only have a certain amount
of decimal digits in a display, you need rounding, how do you
tell a user that  X+n*2**Y < X+(n+1)2**Y   with Y let's say -25
on a display with 3 digits after the second? 

> 
> Comparisons other than simply seeing which occurs before another
> (i.e., finding the exact time difference in seconds, say, between
> two timestamps) is much more complicated when calendric dates are
> involved.  It's necessary to convert from format to format -
> seconds, minutes, hours, days, weeks, months, years -- involving
> different bases, with odd rules such as leap years and leap
> seconds.  The latter can't be computed in advance, so lookup in
> historic leap-second tables is needed to compute the difference.
I do not see that an important usage is to measure time differences.
As far as I remember, the most important applications are to associate
time in the sense of sequence to a datum, in order to be able to
decide whether the datum (its hash) existed before some date. 

If I have an expiriation date of let's say today, then I am
very rarely concerned whether this is 150 or 160 days before
the end of the millenium. (The fact that everybody just begin
counting these days is a kind of prove.) 

In fact there are cases where date differences may be important:
When you send an invoice and you attend a payment. But then
you can have rules that say that you want to be payed 30 days 
later or 15 days after the end of the month or else. There are
tons of different habits.   

> 
> A timestamp which shows the time simply as, say, an NTP timestamp
> doesn't have these problems.  Ignoring leap seconds, the exact
> time difference (down to 2^^-32 second) between two timestamps
> can be found by simply performing a single 32-bit binary subtract.
Imagine two implemenations, one is ignoring the leap seconds, 
another one is not. 

What is the percentage of applications that need to count time
differences? 

> 
> (Elsewhere I've proposed an extension to the NTP time format which
> takes the issue of comparisons across leap seconds into account.
> http://www.ietf.org/internet-drafts/draft-ietf-pkix-bert1-01.txt)
> 
> >  it is not clear how many digits a user agent
> >  should present to a user espcially in case of some precision.
> >  if one requires no loss of information during display then the
> >  tex string becomes horribly long and the complexity of the
> >  display is far away from what can be actually expressed.
> >
> >  "the time stamp is xxxx plus .39876874654854 (+= -2**15)"
> 
> Three digits of accuracy sounds quite good, configurable if
> other lengths are desired.  This is not a serious problem.
Three digits of accuracy is what you have with standard
GeneralizedTime. But how do you compare such time stamps
if you don't have a sequence number? Where do you decide about
the precision of the conversion? Do you want a deciding 
entity to compare the binary time stamp and then tell to
the two parties 12:00:00.123 is after 12:00:00.123? 
Smells like a 1/Y2K problem. 
Or does the TSA indicate: Even if I give you binary values, 
I ensure not to issue more than one per millisecond or per 10*-n ?

> >
> >- If a time stamp authority just want to sell stamps without
> >  indication any particular order if they happen to be in the
> >  same second, what should they code?
> 
> I think this should be forbidden.  It should always be possible to
> take a sequence of timestamps and put them in their issued order.

I actually disagree: When you need a time stamp to prove that you got
it before midnight, it is not necessary to know whether you got it
before or after someone else. In fact you should be able to only get a
yes/no response when asking for 'i need a time stamp before a
certain date', and the TSA just indicates the date you want and not
its current date and just indicating whether it is before or after
that date.  

> 
> >- Using the NTP logic to carry subseconds seems to be a left over
> >  from a misunderstanding of requirements for "secure time" and
> >  "time stamp". using the time stamp protocol to provide secure
> >  time doesn't seem the a good approach anyway (I would start
> >  using a kind of NTP over secured channel, IPSEC, TLS, etc.).
> 
> I agree with that, though the time format could be interchangeable.

The current spec is a mixture of binary and textual data. 
Maybe a CHOICE of either GeneralizedTime with fractionals or
a complete binary format would be a compromise. choices should
reuse as is existing well established formats and not create
new bastards in order to be able to reuse existing code of
displays converters etc. 
There shouldn't be two many elements in the choice in order to
avoid interoperability problems anyway. 

using an unmodified NTP like format as *the* binary choice
seems ok with me.

A TSA may implement whatever it wants (this is policy).

In the TSA request one should be able to indicate the time
format that is desired/acceptable by the client.  

Peter Sylvester