Subject: Re: Lets Standardize Time Representation Formats!!!: WAS Re: New TSTTime definition

From: [email-masked]
Date: Thu, 5 Aug 1999 11:47:28 -0400

Paul Koning <[email-masked]> on 08/05/99 10:55:40 AM

To:   [email-masked]
cc:   [email-masked], [email-masked]
Subject:  Re: Lets Standardize Time Representation Formats!!!: WAS Re: New
      TSTTime definition

>>>>> "tog" == tog  <[email-masked]> writes:

 >> good[0] one already exists?" rant).  There's already a standard,
 >> well-defined way to
 >> represent time values, why invent another one?

 tog> becuase there is nothing here except the time data. If we want
 tog> an accompanying sense of credibility for the timedata then ASN.1
 tog> would needs a signedTime format. The actual representation of
 tog> the timedata is simple, its what is mandated with it to prove
 tog> its credibility that's the question here.

Exactly.  You do need to take an unsigned time format and apply a
signature to it.  That isn't the issue.

The issue is: why does the TSTTime consist of GeneralizedTime plus
more stuff, when that additional stuff merely duplicates in a
confusing way what you can already represent with GeneralizedTime?

[Tom Gindin]   I think that the main reason for having any other field in
TSTTime is that DER encoding of GeneralizedTime removes trailing zeroes, and
thus precision cannot be inferred from it.  The only field other than
GeneralizedTime which is really needed is precision, because DER eliminates the
possibility of correctly inferring the precision from the value presented.

     paul

---

From: Paul Koning <[email-masked]>
Date: Thu, 5 Aug 1999 13:04:01 -0400

>>>>> "tgindin" == tgindin  <[email-masked]> writes:
> The issue is: why does the TSTTime consist of
> GeneralizedTime plus more stuff, when that additional stuff
> merely duplicates in a confusing way what you can already
> represent with GeneralizedTime?

 tgindin> [Tom Gindin] I think that the main reason for having any
 tgindin> other field in TSTTime is that DER encoding of
 tgindin> GeneralizedTime removes trailing zeroes, and thus precision
 tgindin> cannot be inferred from it.  The only field other than
 tgindin> GeneralizedTime which is really needed is precision, because
 tgindin> DER eliminates the possibility of correctly inferring the
 tgindin> precision from the value presented.

That's true. 

The field under discussion, I think, is "subsecond".

	paul