Subject: Re: New TSTTime definition

From: Peter Sylvester <[email-masked]>
Date: Tue, 3 Aug 1999 13:54:18 +0200 (MET DST)

Hi,

- A binary fraction of time always needs a calculation (conversion
  to decimals. 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)"

- GeneralizedTime does not need much work to present it to a user.
  It seems to me that fractions in GeneralizedTime are intended
  to convey information about higher precision time values;
  I propose to allow subseconds in the genTime at least when 
  the other precision stuff is not present. 

  BTW: If a certificate says "notafter 23:59:59" means not after
  the end of the second that starts with 23:59:59 because during
  the whole second a clock shows that value.

  If time stamps with a precision below a second are necessary
  then it might also be necessary to change certificates, i.e.
  extend the precision.

- Is the serialnumber in the TSTTime unique within the second
  expressed by genTime, or globally? (I have the feeling that
  
> > 1) when associated with the name of the TSA and the genTime it may
> > be used to unambiguously reference a Time Stamp token for auditing
> > purposes. In order to allow anyone to easily reference any token
> > from any TSA, this field is mandatory.
  indicates uniqueness within a second, if so, ok.

- 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? 

- 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.).

Peter

---

From: Michael McNeil <[email-masked]>
Date: Wed, 04 Aug 1999 11:27:25 -0700

Peter Sylvester wrote:
>  to decimals.

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.

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.

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.

(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

Three digits of accuracy sounds quite good, configurable if
other lengths are desired.  This is not a serious problem.

>  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.

>  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.

Regards,
Michael McNeil