Subject: RE: Time Stamp: Usage of TDTs

From: "Bill Lattin" <[email-masked]>
Date: Thu, 1 Jul 1999 07:39:15 -0700

Michael,

I suppose that if a TDA issuing this type of TDT wanted to perform the other
activities associated with a TSA it could; however, I don't necessarily see
a merging of the two since the business issues associated with each
(liability, customer support, application interfaces, policy support, etc)
are quite different.  Also, not all applications requiring a time stamp need
that level of accuracy - hence the variation in service offerings I
previously mentioned.

Cheers,

Bill

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, June 30, 1999 17:23
> To: [email-masked]; Denis.Pinkas; [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> Subject: RE: Time Stamp: Usage of TDTs
>
>
> Bill,
>
> Ok, another question: If one day NIST will implement TSA services itself,
> would I, as a client, need a TDT in the TST produced by a NIST server? I
> guess no.
> In general case, if a TDA can attest to the quality of time (because it
> knows it better, presumably), what stops it to provide TSA
> services itself?
> So the clients can go 'right to the source', and get a 100%
> guaranteed pure
> time reference, instead of having to worry about secondary verification,
> etc.
>
> Waiting for replies...
>
> Regards
> MichaelZ
>
>
> -----Original Message-----
> From: Bill Lattin [mailto:[email-masked]]
> Sent: Thursday, July 01, 1999 7:12 AM
> To: [email-masked]; "Denis.Pinkas[Denis.Pinkas"@bull.net];
> [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> Subject: RE: Time Stamp: Usage of TDTs
>
>
> Michael,
>
> Thanks for the feedback.
>
> Depending on the application, a client could be very interested in
> "certified evidence" being located in a TST.  For example, in a currency
> arbitrage or stock trade situation one coud envisage being able to prove
> that a trade was placed at a certain time.  The real question is what
> evidence is good enough?  Is it a contractual agreement that the local
> TSA's clock is sufficently accurate and precise or is will there be a
> mandate to use the clock from a National Timing Authority?
>
> The answer is both.  We are not advocating that this type of TDT replace a
> local TSA clock; both models are valid.  We just want to enable the use of
> the National Timing Authority clocks since we believe that a number of
> applications will insist on having time traceable to them.  As a current
> example (although one for which PKIX time stamps will be too late for the
> initial phases) is the NASDAQ OATS system.  This order tracking system is
> required to use timing from NIST (the US' NTA).  The healthcare system in
> the US is also extremely sensitive to time, and we expect that many new
> applications will need to be linked to an NTA timing source rather than a
> local source.
>
> Further, I'm sure we all agree that the timeStampToken needs to be a
> persistent data object.  For example, e-mail would normally be
> considered to
> have low requirements for time-stamp trust.  However, 3 years
> down the road,
> a given e-mail and its time of origin may be pivotal in a legal case.  If
> the trust of the time in the timeStampToken can be embodied with
> a party in
> addition to the entity possessing the TSA, the timeStampToken can better
> meet the requirement to be a persistent data object.
>
> You are right that a request of a single TDT does not guarantee future
> performance from the TSA.  For applications that need
> traceability to NIST,
> a TDT will be needed per time stamp.  This is an important extra
> benefit, a
> TST with its own instance of a TDT can provide 'guaranteed' time
> independent
> of the clock within the TSA.  Other applications, which are not as
> sensitive, can operate as you have suggested - by agreement on policy that
> the TSA is doing the right thing.
>
> The bottom line is that the use of a TDT in this manner enables a
> new class
> of applications which require explicit, provable traceability (with
> associated audit trails) to an NTA.  The TSA operation is enhanced because
> it can offer multiple types of service.
>
> Cheers,
>
> Bill
>
>
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]
> > Sent: Tuesday, June 29, 1999 23:10
> > To: [email-masked]; "Denis.Pinkas[Denis.Pinkas"@bull.net];
> > [email-masked]
> > Cc: [email-masked]; [email-masked]; [email-masked];
> > [email-masked]
> > Subject: RE: Time Stamp: Usage of TDTs
> >
> >
> > Must admit it makes more sense now.
> >
> > However, the question is why would a TSA's client require or be
> generally
> > interested in a "certified evidence of the TSA's diligence"?.
> This is what
> > you propose, isn't it? Sorry if I misunderstood it.
> >
> > Would it be sufficient for the TSA just to claim (out of band,
> using legal
> > policy statement or else) that it is using such and such time source(s),
> > with a timePrecision field present in each TST?
> >
> > A client would then decide, based on the policy information (clock
> > resolution, synchronization with NTA, reliability, etc), if that
> > particular
> > TSA is suitable for use.
> >
> > I can anticipate an argument that the TDT can be requested by the client
> > just once, to check how good is the TSA's timing. But this does not
> > guarantee that the consequent TSTs will be issued using the
> same clock, or
> > using the same clock-to-NTA synchronisation. If this is
> guaranteed by the
> > TSA's policy, and we are going to trust to what the policy
> > promises, then as
> > well we can trust the rest of it (i.e. when/if it states that
> the clock IS
> > synchronised with NTA).
> >
> > Probably, there are business cases where having TDT in a time
> > stamp would be
> > a nice feature. Looking forward to hear more.
> >
> > Regards
> > MichaelZ
> >
> >
> > -----Original Message-----
> > From: Bill Lattin [mailto:[email-masked]]
> > Sent: Wednesday, June 30, 1999 5:21 AM
> > To: [email-masked]
> > Cc: Dave Robinson; Ron Holm; Mike Duren; Greg Dowd
> > Subject: Time Stamp: Usage of TDTs
> >
> >
> > All,
> >
> > Over the last few weeks, there has been considerable discussion
> > on the need
> > for TDAs and their corresponding TDTs.  Much of the debate has been on
> > whether or not TDAs really add anything essential.  The heart
> of the issue
> > is whether or not the TSA is producing suitably trusted and
> accurate time.
> > It has been argued that if the time is accurate and trusted,
> then TDAs are
> > redundant (de la Vega and Zolotarev) and therefore should be eliminated.
> >
> > Rather than use TDAs to provide secondary non-time information to
> > substantiate a TST, an alternative use is for a TDT to convey traceable
> > trusted time certification from a National Timing Authority (NTA) (e.g.
> > NIST) to the TSAs.  Rather than conveying something indirect like stock
> > market closing data, this new type of TDT could be used to show, in a
> > non-repudiatable manner, that: (i) a TSA's clock is accurately
> > synchronized
> > to the NTA's clock ; and/or (ii) the time of creation of a TST embedding
> > such a TDT is traceable to the NTA.
> >
> > We are working with the S/Time group to create a protocol to reliably
> > distribute time from an NTA to allow lower clocks in a timing
> hierarchy to
> > be accurately and reliably synchronized to the NTA's clock.
> The result of
> > this process is a digitally signed certification that a clock
> is properly
> > synchronized to the NTA.  This certification can be embedded in a TDT to
> > prove that the time in the TDT or TST comes from a clock which has been
> > synchronized to an NTA.
> >
> > Use of a TDT in this manner accomplishes a number of things:
> >
> > 1.  It directly enhances the quality of the TST by providing both
> > a link to
> > UTC and traceability to NIST (or appropriate NTA);
> > 2.  It can be used to synchronize multiple TSA's to an NTA so
> > that the TSAs
> > can produce timestamps per NIST UTC (for instance) rather than
> their local
> > clock.
> > 3.  It will aid certain electronic commerce implementations since
> > the TSA's
> > clock can be shown to be directly traceable to an NTA.
> >
> > Thus, we urge the group not to abandon TDAs and TDTs, but to consider an
> > alternative use for them that would contribute additional,
> > directly relevant
> > timing information to enhance the operation of the TSA and the
> quality of
> > its TSTs.
> >
> > Regards,
> >
> > Bill
> >
>

---

From: "Michael Duren" <[email-masked]>
Date: Thu, 1 Jul 1999 12:55:40 -0400

I agree with Bill that a TDA could issue tokens in the same way that a TSA
does.  His point about liability and business issues is very true to life.

Going back to the definition of a TDT, the TDT to TSA relationship is many
to one.  The TDT concept allows for collaboration of temporal information
from more than one source.  Since the TDT is also signed, this collaboration
greatly strengthens the TSA trust model.  With this in mind, a TST can
include temporal information from more that one NTA-authenticated TDA.  In
addition, companies and organizations might have their own TDA.  Policies
then could be defined that specify what TDA's must be included in a given
timestamp.

To move to a real life example, if company X and Y are doing business and
those companies reside in different countries, would it make sense for them
to obtain timestamps that are traceable to their respective NTA?  Also,
perhaps one or both companies maintains their own TDA, would it be
reasonable for the timestamping standard to allow for inclusion of their own
TDTs in TSTs that involve their company?

Feedback is welcomed.

Sincerely,

Mike Duren

-----Original Message-----
From: Bill Lattin <[email-masked]>
To: [email-masked] <[email-masked]>; Denis.Pinkas
<"[Denis.Pinkas"@bull.net]>; [email-masked]
<[email-masked]>
Cc: T. Mark Hastings <[email-masked]>; [email-masked]
<[email-masked]>; [email-masked] <[email-masked]>;
[email-masked] <[email-masked]>; [email-masked] <[email-masked]>
Date: Thursday, July 01, 1999 10:41 AM
Subject: RE: Time Stamp: Usage of TDTs

---

From: [email-masked]
Date: Fri, 2 Jul 1999 10:37:31 +1000

Michael,

Thinking about two companies - if they are really concerned about mutual
trust, why would not they just use the same TSA? Which they both agree upon,
and is reliable and time-accurate.

Also, if a company runs its own TDA, a TDT can be included into a TST
upfront, by merging the TDT with the data before sending a request to the
TSA. The TDT can be hashed together with data, or it can be just appended to
the hash. 

<<Though I do not quite understand a particular value of a private TDA - if
it is a TTP, then it should not be the company's own. If it is not a TTP,
then who would trust it and why would I need to attach it to anything? And
it can not attest to the accuracy of time produced by the TSA.
Non-repudiation? can be done without TDT. Could you please explain?>>

Another matter with a TDA producing verification for the quality of time by
TSA: could it happen that a TDA decides not to verify the time quality of a
particular TST? I guess so, otherwise why to have it at all, if it always
OKs everything. In a situation like that, what should the TSA do? What
should a client do, when it gets a TST that includes a
'time-was-not-verified' TDT? Getting quite messy, don't you think?

I appreciate that there could be quite exotic situations, however. It is
just questionable if the standard should be overcomplicated to cater for
something that might never be even used, or can be achieved by other means.
But this is a matter of taste, I reckon.

Waiting... 

MichaelZ

PS Pity it is 14+ hours time difference between most of you guys and me.
What is the benefit of having fast e-mail, after all? :-)

-----Original Message-----
From: Michael Duren [mailto:[email-masked]]
Sent: Friday, July 02, 1999 2:56 AM
To: [email-masked]; Denis.Pinkas; [email-masked]; Bill
Lattin
Cc: Chet Hosmer; David Robinson; Ron Holm; Greg Dowd; T. Mark Hastings
Subject: Re: Time Stamp: Usage of TDTs

Feedback is welcomed.

Sincerely,

Mike Duren

---

From: "Michael Duren" <[email-masked]>
Date: Thu, 1 Jul 1999 23:21:03 -0400

Thanks for the response.  I know what you mean about the time difference, so
I decided to stay up a bit later tonight.  (So please excuse a typo or tw0)

>and is reliable and time-accurate.

How do you prove that a TSA is time-accurate?  I don't see anything in the
TST that allows this, just a signature?  Because the signature is valid,
does that mean the time is accurate?  Can this only be solved by placing
trust in a policy or by relying on out of band information?

>'time-was-not-verified' TDT? Getting quite messy, don't you think?

Sure that could be messy.  (Lots of things are messy)  It could be that a
TST should have a TDT in it but does not (perhaps the request was denied, or
the TDA was out of service, or the TDT signature could be invalid).  But
this problem you have introduced is not brought about by the existence of a
TDA.  What ever mechanism that is being used to prove to the world that a
TSA's time is valid can fail or be questioned.  Perhaps a TSA is to undergo
a strict audit as part of some contractual obligation, what happens if the
auditor is late or fails to show up or if the actual time is shown to be
inaccurate; I think that is just as messy if not more so.  At least with the
proposed use of TDTs, the client can instantly verify the presence and
validity of the TDT information and then resubmit or incidate a problem
right away.  The result of an audit or out-of-band information regarding the
accuracy of a TSA's clock may not be readily available.  However, I am sure
that a company that has a TSA with an invalid clock will run out and tell
the world right away.

(BTW, it has not been suggested that the TDA holds any authority over the
time of a TSA).

>But this is a matter of taste, I reckon.

Why would it take an "exotic situation" before NTA traceable time is
required?  I think Bill pointed out situations where this may be useful now.

Why is it unreasonable to include information in the Timestamping protocol
that allows clients to trace the time value in the stamp to some timing
authority?  If the TDT can contain time values that are traceable to a
Timing Authority, then why not define a protocol that allows those tokens to
be included in the timestamp?

The TDT is an optional field.

Hope you have not been waiting too long.

Mike Duren