Subject: RE: Lets Standardize Time Representation Formats!!!: WAS Re: New TSTTimedefinition

From: [email-masked]
Date: Tue, 10 Aug 1999 17:02:57 -0400

> The only thing missing from this is an indication of the accuracy
> of the time value.  This is easily accomplished by adding a field
> that indicates the accuracy.  So the resulting ASN.1 would look
> something like:
>
> TSTTime ::= SEQUENCE { genTime GeneralizedTime, errorFactor
> INTEGER DEFAULT 0 -- genTime is correct to within (2**errorFactor)
> of the actual time.  }

But surely, since GeneralizedTime contains a subsecond facility, we
can simply assume that the GeneralizedTime is accurate to the precision
given?

In other words: If errorFactor implies a greater precision than
is provided in genTime (for example, genTime provides time to 1/10th
of a second and and errorFactor implies precision to a microsecond)
then errorFactor cannot be trusted; If errorFactor implies a smaller
prcision than is provided in genTime, why not simply leave off the
trailing digits of genTime?; and if errorFactor implies an error of
more than a second, why would anyone use that TST?

[Tom Gindin]   This is where we started on this topic.  The DER standard (X.690
section 11.7.2) requires that trailing 0's be truncated from the fractional part
of a GeneralizedTime, and that the entire fractional part be omitted if it
consists of all 0's.  Therefore, inferring the precision from the value given
for GeneralizedTime will often (10% of the time for any precision closer than a
second) result in understating it by at least a factor of 10.

What actual purpose does errorFactor serve?

Cheers,

William

---

From: Michael Zolotarev <[email-masked]>
Date: Thu, 12 Aug 1999 14:16:21 +1000

Dear All,

I've been away for a week, thus putting myself into a surprisingly favorable
position of not been dragged into the 'discussion rampage'. Instead, after
coming back and run-surfing through 200+ messages (oh dear), a kind of a
'general' picture has emerged.

Unfortunately, as it appears to be, we are loosing track of what we have
started from and what we are trying to resolve/achieve. The things are as
messy and merry-go-roundish as they have never been, and it does not seem
that the end is near.

Hoping to help the discussion out of the loop, I separate all various
problems into 4 groups: Model, Trust, Precision and Accuracy, Presentation.

*** Model ***
The originally proposed model ( TSA as a TTP, maintaining a source of timing
information and issuing time stamps on requests by external clients) is
being somewhat dissolved and obscured. Even up to a point when people new to
the subject found themselves completely lost. Stephen has already raised his
voice, asking to stick to the original model. I can not agree more. I
suggest we do not question the model with regards to that draft. The other
use models are valuable and should not be discarded, but should we discuss
them outside the context of the current TSS draft?.

*** Trust ***
The main questions to be answered with regards to the trustworthiness of
time the TSA puts into a token - 
1) do we trust the time in the token simply because we trust the TSA, its
policy and diligence. 
2) do we need an extra prove/trust_chain present in each token, as the
evidence that the time is 'right'.
3) do we need anything extra in a token to preserve its value of an
undeniable evidence 10 years after its creation.

To me, (3) is simple - if you trust a token today, you should legitimately
trust it later. It should not matter if the TSA is still around, the time
was changed because the earth slowed down, or anything else. Similar to "if
a transaction that used a certificate was authenticated and validated today,
its validity should be acknowledged in the future, even if the CA who issued
the certificate no longer exists".
As a proponent of (1), I've been trying to see the avail of having extra
time-source-trace data in the token. So far, I am failing to see how it can
be done unless:
a) TSA takes ALL time values, for EACH token, directly or indirectly, from a
'trusted' source (NIST). Thus effectively precluding using local (even
closely synchronised with NIST) time sources.
AND
b) Each time source (or "time base", using the BERT dictionary), keeps a log
of all requests
AND
c) Each request is signed by the client, so the record in the time base's
log is rightly associated with the client.

Unless I'm wrong in my understanding, the a)b)c) above make everything too
overcomplicated.

*** Precision and Accuracy ***
I guess this is where most of people have finally come to common grounds: We
need sub-second resolution, and we need the accuracy. Where the accuracy is
defined as a diapason, deviation from the 'absolute time'. The guaranteed
minimum accuracy should be defined in the TSA policy statement, allowing a
customer to chose a provider. The actual accuracy can be placed in the
token, reflecting the current conditions. The accuracy can NOT be greater
then a precision (i.e.. 12.30'17'' +- .1 is fine, but 12.30'17''001 +- .1 is
wrong).

*** Presentation ***
Believe or not, this is were the discussion started. There are dozens of
comments on the subject, and I will spare myself from reiterating through
various proposals. It is just technical, and hopefully we will get it right
there. However, I liked a suggestion (I think it was Todd) of loosing the
TSTnfo format a bit, by allowing inclusion extra data in case we need it.
This may be a wise alternative, to pacify the various parties.

Regards
MichaelZ

Hoping it will help the discussion to straighten up :)

---

From: Peter Sylvester <[email-masked]>
Date: Thu, 12 Aug 1999 13:57:52 +0200 (MET DST)

> them outside the context of the current TSS draft?.

A TSA as a third party service is only one of the possible services
that may be necessary in order to provide legally acceptable
dematerialized documents. 

Using the same format for a secure document and a time stamp, namely CMS is
a good thing IMHO. In other words, a time stamp itself is simply a signed
document, and as such similar or identical procedures to validate and verify
the content can be use.

Another element is that the result can become an signed attribute of another
signed document thus binding together data and additional information.

As it is indicated in the DCS text, a time stamping authority becomes just
one example of a more general model. An entity communicates with other
entities in order to distribute or collect information in order to
enhance the value of a document. 

It seems that what has been asked for was to open up the TSTInfo field
for two different purposes (see later under presentation); 

> the certificate no longer exists".

"Simple"? Depending on the final usage and value  (a concept that in itself is
a moving target) you may need to use a network of data to provide evidence that
something exists, had happened, etc. In other words, you get statements like. 
I claim or believe that something is good because this and that other entity told
me that they have verified some other data, and I know that they probaly don't
lie or that they assume a risk because they have shown the an assurance policy
signed by xyz and the government, etc. 
But in the basic argument I agree: At some point, you just have to believe. 

> Unless I'm wrong in my understanding, the a)b)c) above make everything too
'Time stamping' is not 'everything'. If one tries to solve 'everything'
by using just time stamping, indeed things become overcomplicate as you
say. Replace the word 'time stamping' by 'data certification' (where
data can be time) for example. higher level data may have a different value,
thus they may justify additional effort.

> then a precision (i.e.. 12.30'17'' +- .1 is fine, but 12.30'17''001 +- .1 is
In your model the accuracy is not needed. 12.30'17'' is always different
from 12.30'18'' if the accuracy is less a second += .5 What does an accuracy
of .1 second buy you if your precision if one second.  

> This may be a wise alternative, to pacify the various parties.

2 different needs:

- A format that is not almost printable calender based like generalizedtime,
  as initial proposal think about a REAL representing international
  atomic time. but: how many implementations can convert correctly an NTP
  time into a correctly encoded DER REAL :-)

- An format where the TSTInfo is just another Token from another provider
  (just using a SignedDocument). (cf DCSTime)

Some so called complex things may have much nicer and simple features
than their subdimensional real or imaginary projections. 

> Hoping it will help the discussion to straighten up :)

/P

---

From: Michael Zolotarev <[email-masked]>
Date: Mon, 16 Aug 1999 13:45:14 +1000

>signed document thus binding together data and additional information.

TimeStamp is currently defined as a CMS's signedData, isn't it?

>enhance the value of a document. 

Even with DCS, time stamping may still maintain its value as a separate
service. DCS would reach out to a TSA in order to get a TS token, and
encapsulate it. Right?

>thus they may justify additional effort.

But I was talking about time stamping, so it was "everything" in the context
of the mail :). Maintaining "chain of trust" in time stamping makes "it"
overcomplicated.
Chain of trust may be perfectly legitimate for other data certification
services, of course.

>of .1 second buy you if your precision if one second.  

12.30'17'' is always different from 12.30'18'' only if your clock is
accurate within a second. What if it not, and the clock's deviation from
"real" time is +- 2 seconds? In other words, "the time is 12.30'17'' +-
2sec". 
But you are right - I've made a mistake. Should the definition rather be:
"The units of accuracy MUST be the same as the precision's factor: i.e.
12.30'17'' +- 1 sec. 12.30'17''.5 +- .1, 12.30'17''.15 +- .03"

>  (just using a SignedDocument). (cf DCSTime)

I agree in principle that we need more then one time presentation format
here, and probably more then just 2. 
However, the International Atomic Time format can be only an optional
feature, unless we mandate that all TSA read time from the IAT source.

As a common denominator, I believe ASN1 GeneralizedTime + accuracy is a good
choice. Any other time presentation formats and provider's tokens can be
included as optional fields into the TSTTime. The problem is 1) how are we
going to identify the optional elements - using OIDs or tags, and 2) do we
define the set now or leave the list open?

Should we introduce a TSTTime::Version element? This would allow us to move
on, assuming that any enhancements can be implemented later, under different
version numbers?

TSTTime ::= Sequence
{
	version	INTEGER [0]
	tstTime	GeneralizedTime  // MAY include sub-second precision
	accuracy	INTEGER OPTIONAL // interpreted as units of the
tstTime's precision
	// serialNumber ??? Sorry, I am not quite sure what was the
conclusion about having it here
}

Regards
MichaelZ