Subject: Re: Usage of TDTs

From: "Michael Duren" <[email-masked]>
Date: Thu, 8 Jul 1999 10:25:46 -0400

Stephen,

I understand your point regarding the scope of the IETF WGs.  However, it
seems as though you are selective in the issues that you choose to address.
Perhaps it is time to reset the debate regarding the TDT.

As far as the standard is concerned, the TDT is an optional field that was
originally put into the specification to provide additional justification of
a TSA's time in the form of signed, temporal information.  Unfortunately, it
seems as though the examples that were given in the specification were not
well thought out.

Members of the group were quick to point out that temporal information such
as “stock quotes” does not add additional credibility to a Timestamp.  The
group has since been debating as to whether or not the optional TDT should
remain in the specification.

In the meantime, Bill Latin has introduced a usage for the TDT that has both
commercial application and can enhance the timestamp protocol's trust model.
Bill's idea of using the TDT to provide NTA traceable time is an excellent
example of how to use the TDT. He has simply asked the group to keep the TDT
in the specification.

I can certainly stop here and argue: the optional TDT was in the original
specification - someone found a use for the optional TDT - and now that same
someone has to argue to keep the optional TDT in the specification.  I don't
get it.

Perhaps Bill's idea can add new dimension to the fundamental idea of the
TDT.  In regards to a timestamp, we must ask, how do you know the value of
time in the Timestamp is valid?  And, how do you prove this validity to
someone else?  Those are fundamental questions about timestamping that
should be effectively addressed by this standards body and by this
specification.  The only answer that I have heard so far regarding trust in
time is that everyone must trust in policy.  The client must trust in a
policy, and anyone that is to believe the validity of a timestamp, must also
trust the same policy.  Trust in policy may be fine for many users, but I
suggest we can do better.

It has already been suggested that a TSA might deploy some sort of audit
procedures to maintain valid time.  Certainly, a trustworthy TSA will deploy
redundant mechanisms for maintaining time accuracy.  TSA's could use GPS,
specialized hardware, redundancy, NTP synchronization, auditing, and perhaps
some new, innovative technology or application.  But how does the use of
those mechanisms, and how does trust in policy allow a client that has a
timestamp to prove to someone else that the actual time in the stamp is
valid.  There is nothing in the TST to prove that a TSA's clock was
accurate.  There is no evidence in the timestamp that suggests a TSA's
audits have been successful or that procedures to maintain a TSA's clock
have been properly followed.

Latin's suggestion to put NTA traceable time in the TDT adds a new dimension
to the TDT trust model.  Placing this trusted time in the TDT allows
multiple, signed time testimonies that could reasonably come from more that
one NTA.  Placing this trusted time in the TDT allows a separation of roles
and responsibilities so that trust in time is not dependent on one signature
or on a policy.  Placing this trusted time in the TDT allows clients to
instantly recognize and authenticate information that links the timestamp to
a NTA.

In addition, the TST that contains multiple, signed testimonies of time can
be much more trustworthy than the TST with one signed testimony of time.
Corroboration of time from multiple, independent authorities is very
difficult to dispute and can be achieved through the TDA.

In a real life criminal case, it is much easier to prove that someone was
“at a certain place at a certain time” if you have multiple eye witnesses
than can attest to a person's location.  Why, then, build a timestamping
system that limits the number of “electronic witnesses” to one?  The first
question that my defense attorney will ask is "how can you prove that the
time was valid on the TSA's clock? Policy? Audit? How many people verified
the clock?  How often was the clock verified?  Can you prove the
verification?"

With that said, the question for the group is not about implementation
details, or about undue marketplace advantages, or about complexity, or
about -what if this and what if that-, the question for the group is simply
this: Does it make sense to remove the optional TDT from the timestamp
standard?

 Sincerely,

Mike Duren

-----Original Message-----
From: Stephen Kent <[email-masked]>
To: [email-masked] <[email-masked]>
Cc: [email-masked] <[email-masked]>
Date: Wednesday, July 07, 1999 6:04 PM
Subject: Re: Usage of TDTs

>Todd & Bill,
>
>I think we are seeing some serious disagreements here, in part due to
>fundamentally different assumptions about implementations and the role of
>IETF WGs.
>
>This WG, like all others in the IETF, develops protocols as a means of
>specifying interoperability.  We don't develop implementation
>specifications; we leave that to the implementors, so long as they achieve
>the interoperability requirements of the protocols.  For example, the
>security offered through the use of a protocol such as SSL, IPsec, or
>S/MIME is heavily dependent on the quality of the implementation.
>Moreover, when these protocols are implemented on top of an insecure OS, an
>active attacker has a whole new set of opportunities to circumvent the
>security offered by the protocols.  This is a valid concern, but it is
>outside the scope of IETF standards.  (You can find informational RFCs on
>operational and implementation security issues, but they are not
standards.)
>
>When you criticise the notion that a TSA can be relied upon by its clients
>to provide accurate timestamps, and cite the insecurities of OSs, you have
>stepped outside of the bounds of our WG charter, and of IETF standards in
>general.  One could elect to implement a protocol supporting a TSA in a
>dedicated device that is immune to these criticisms.  It is fair for us to
>consider, in the course of protocol design, when we may do to facilitate
>more secure implementation, without prescribing implementation details.
>However, as a matter of policy, I would not skew a protocol design based on
>any technology that gives undue advantage to any given vendor, e.g., based
>on use of a patented technology, dominant market position, etc.
>
>Steve
>

---

From: Denis Pinkas <[email-masked]>
Date: Thu, 08 Jul 1999 18:07:49 +0200

Michael,

The final question placed at the end of your E-mail is the following:

" Does it make sense to remove the optional TDT from the timestamp standard? "

I do not think this is the right question. The question should be instead:

"For what reasons should we maintain the optional TDT from the timestamp
standard? "

I am not convinced that the use you describe can only be supported by TDTs.

Detailed comments are embedded in your E-mail.

> suggest we can do better.

As you say, this is fine for most users. I do not see the necessity to do
better.

> have been properly followed.

The TSA claims that it is accurate up to a precision that may be good *or bad*.
We now have such a field that can express a *variable* accuracy of the time.

If someone does not trust a TSA it should not use it. In some cases, for example
when building a contract, A trusts one TSA but B trusts another one. The
solution is very simple: use two time stamps instead of one. The contract will
only be valid, if it bears the two time stamps. Two is not enough ? Use three .

> instantly recognize and authenticate information that links the timestamp to

The verifiation of such Time Stamps would be much longer and complicated.

> than can attest to a person's location.

Hence the solution is very simple: "use multiple eyes" means "use multiple time
stamps" - NOT a single time stamp that bears different proofs in it. This is
much simpler to implement

Regards,

Denis

> Why, then, build a timestamping