Subject: RE: Timestamp: TDA in timestamp

From: "Juan G. de la Vega" <[email-masked]>
Date: Thu, 10 Jun 1999 09:38:32 +0200

All,

    I think that TD issues need clarification within this draft. Assuming
that temporal data are values derived from the result of a given
unpredictable, high-entropy, and *recent* event (if this is not so, then I
doubt the utility for this and please disregard the rest of the message),
from the very theoretical point of view this kind of data are useful per se.
Their unpredictable nature makes them suitable for providing proofs of
"after than", the association of a given datum with these temporal data
(i.e. hashing together or signing) provides that the datum existed after
that the event ocurred (It is the case of the photograph of a hostage
holding a newspaper).
This is useful to construct proofs of possesion, to prevent from forward
dating and to provide leaps of existence (after-before). It is therefore
sensible to think of a TD Service as an independent service provided to end
users and not only to TSAs.

The interest of these data is their unpredictable nature and the possiblity
to check its validity using widely spread resources afterwards (dow jones
average closing value is a good example).
So the question is whether it is needed to sign those data, since no further
value is added (verification process implies the query those available
trusted sources not the formal verification of a signature). If a TSA is to
provide an interval service, then temporal data should be provided by the
TSA itself for the trust on temporal data is in the data themselves not
provided by external wrappings (i.e. the authority signing). So it may be
understood that a TDA is a TTP in the sense of assuring a given *quality* of
the events selected to provide temporal data.

Summarizing, TDS can be a useful service itself, the value is in the data
themselves (everyone who has access to that data could become a TDA, even
the client of the TSA). In terms of trust, TDA does not grant anything but
the impossibility to forward date, so if the TSA is trusted for providing
accurate time there is no need for TDA tokens, in this case TDA is not
supplementary, it is redundant in terms of time (i.e. event result contained
in TSToken will always be available previos to the time stamped).

regards,
Juan.

>Well, I guess the reason for having TDA tokens INSIDE time stamp token and
>OPTIONAL is explained by the draft as "...TDA... provides supplementary
>evidence for the time...". The time stamp is the prime goal ("datum existed
>before a particular time"), and anything else (i.e. "datum existed during a
>particular event's life span") is supplementary and largely redundant
>knowledge.
>To me, the fact that TDA handling and associated structures are described
in
>the dark and gloomy corner of the draft, signifies that the authors have
>reasonable amount of doubts in potential usefulness of TDA tokens. I feel
>that as the time stamping infrastructure matures, the TDA will eventually
>either 1) evolve into a separate service, used directly by the clients,
>supplying time stamped data (exactly what you have proposed), or 2)
>disappear from the PKI fields.
>
>After all, why do we need any supplementary evidence of timing if you trust
>TSA? If you do not trust TSA, then how can you trust TDA token obtained and
>verified by [non-trusted] TSA? The complexity of dealing with TDAs does not
>seem to justify the value of extra supplementary info in the time token.
>Would like to hear any other opinions.
>
>Regards
>MichaelZ
>
>
>>Why are TDA tokens included in timestamp tokens?  Why not the other way
>around?  Why shouldn't clients go directly to a TDA?
>
>>A TDA says a datum existed before a particular event.
>>A TSA says a datum existed before a particular time.
>>Their similarities should means similar syntaxes can be used for their
>tokens & similar protocols for interacting with them.  Perhaps even common
>syntaxes and >protocols with a small number CHOICE or OPTIONAL fields could
>be used.
>
>>Nesting TDAs within TSA tokens, however, does not make much sense.  This
is
>highlighted by the fact that the TemporalDataToken, as used for the
>tdaTokens field of >TSTInfo, is not even defined in the main body of the
>draft standard (it is in an appendix).  Appendix C.3. adds lots of onerous
>requirements to a TSA that it is not >interested in: verifying TDA
>signatures, checking TDA names, nonces, interacting with a TDA, etc.
>
>>If nesting of TDA & TSA tokens is a useful feature
>>Nesting can always be implemented "outside" the protocol by getting, say,
a
>TDA token then having this timestamped (i.e. send the hash of the TDA token
>as a >messageImprint to a TSA).  Attribute syntaxes to hold all the
>resulting tokens would then be useful.
>
>
>>=> remove the tdaTokens field from TSTInfo
>>=> perhaps replace tstTime with
>> value CHOICE {
>> time TSTTime, -- used by TSA
>> temporalData TemporalData -- used by TDA
>> }
>

---

From: "Michael Zolotarev" <[email-masked]>
Date: Thu, 10 Jun 1999 19:44:01 +1000

Juan, James, All,
So, I believe, we all tend to agree that having TDA token inside TSA token
is redundant, right?

I'd like to speculate a bit on the avail of having TDA as a separate
service.

The major difference between TDA and TSA is that a TD token can demonstrate
that the datum WAS STAMPED NOT BEFORE certain time (the photo of a person
with a newspaper was taken NOT BEFORE the newspaper has been published).
My question is - what is the commercial value of knowing that?
It does NOT prove that the document DID NOT exist before (the person could
be there long before the paper was published and the photo taken).
It does NOT prove that the document DID exist before (a man-with-the-paper
could magically appear out of the universe a second before the photo was
taken).
It does NOT prove that the document existed at some particular moment of
time, unless TDA uses services of third-party TSA, instantly making itself
redundant.

So my conclusion is that TD is pretty useless. I am prepared to receive a
lot of mail with a lot of abuse with a lot of happy :).

Regards
MichaelZ

-----Original Message-----
From: Juan G. de la Vega [mailto:[email-masked]]
Sent: Thursday, June 10, 1999 5:39 PM
To: [email-masked]; 'Manger, James'; [email-masked]
Subject: RE: Timestamp: TDA in timestamp

All,

regards,
Juan.

in
is
a