Subject: Timestamp: TDA in timestamp

From: "Manger, James" <[email-masked]>
Date: Wed, 9 Jun 1999 13:49:51 +1000

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: Wed, 9 Jun 1999 19:11:03 +1000

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

tokens & similar protocols for interacting with them.  Perhaps even common
syntaxes and >protocols with a small number CHOICE or OPTIONAL fields could
be used.

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.

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.