Subject: Re: New test TSA available

From: "todd glassey" <[email-masked]>
Date: Mon, 3 Sep 2001 19:56:50 -0700

My Apologies to many of you. This is a another push back against the TSA and
what I believe to be the manner in which criticism to the design or
suggestions for the design have been taken.

As to the complaint Jean-Marc made that no one raised objections, just look
in the archive.  Every time I or someone else objected to the draft we were
slammed. Sometimes politely but most times not. Many times I myself got back
a belligerent blast of  "NO TODD, WE ARE NOT GOING TO..." and I have to tell
you that people just get tired of being beaten up over the obvious.

For the record - I personally have objected to this time stamping protocol
for the exact same reasons now for the last 3 years. Some of them are listed
below for your reading enjoyment. And it seems from the responses that
nobody was willing to hear that in order for a TS Solution to be embraced by
the world it must have some positive Business Value other than just by
trying to sneak it into law. One would think that the protocol has to do
something positive of value for the transaction process or it has no ongoing
value and as such then becomes an overhead.

Look at this from the standpoint of the Business Operator.

Example #1: they are self insured, so what value in their process is a
timestamp over a simple systems audit process and a timebase management
process. Either way the time data coming out of the report generator has to
be believed... so then what value is the TST in this?

If I believe that both of these are OK, then a simple printed report is all
the Evidence they need. If they need to attach entity to the time data
itself, which is at best a legal stretch, then they can easily hash and sign
the time data itself before they stick it in the DB - they don't need a TST
or a TSA to do this. They can do it with scripts inline in a CGI script or
an ASP model easily and quickly. All they would need is a secured site and a
good audit of the operations of the site and the time management regimen and
viola, what timestamps do they need?

If we need to go to court, you bring your timestamps and the CPS/RPA and I
bring my reports and timebase management audits and we will see who
prevails.  So once again I have to ask "why would I want a formal
oken?"  -- As it happens, there are a couple of good answers here, but they
both require TSTokens that are much larger so that they can contain the
material being stamped and carry other payloads for things like Notorial
Seal Info.

Otherwise I just cant see anyway to justify this device. Its true, it is a
simple system for passing "unauthenticated and uncertified" time data to a
limited use stamp token, but there is no specific value relative to the
trust model of whether I have a TSA as a TTP or not. As such it adds nothing
to the trust or indemnity model other than its own cost of operations, and
its something that the same operators couldn't get from an application and a
DB and an accompanying affidavit from the Operators.

Example #2 - The business uses a TSA to timestamp the services it provides
instead of relying on just a single field in a DB. Now there is a totally
secured linkage between the TSA and the client server too, and a relational
linkage between the DB rows and the tokens.

Does this reduce the operating liability? probably not unless you can see
how some externally linked token can reduce the operating risk on the
systems underlying the transaction process.

Example #3 - Two busnesses doing business between themselves in front of the
TTP. - So the TTP watches the transaction and issues a token as the receipt
for this service. The next question then is would the token be enough for a
receipt and myself I vote no. They are too small.

The Points:
------------
The point is that Time Stamping was supposed to be more than just checking
to see whether a signature was valid at some point in time as it was in
TSA Draft version 1. The TSP's only value over existing trust processes is
in creating a token that could memorialize an event. And could do so in a
commercial environment in such a way as to add value to the transaction
model. Or to substantiate some legal requirement in a filing process
although most of these would do just fine with a report from some DB
Application.

Time Stamps of the past and today
------------------------------------
TS's have for 10's or years been instances of time data stored in Databases
and that's it. The fact that the report that the report generator printed
time data on it from the DB as part of an event verification or testimony
has been accepted for some time is also very relevant here.

What then would I use a TST for then? Certainly not just for the creation of
the TST, if its just about testing to see whether a signature is valid there
are many ways to do that. No its ablaut creating some portable evidentiary
token to codify some event. The problem is that this TST is so light weight
and ignores all of the background testimony that it has the same legal value
(IMHO) as the testimony of the systems operators. And that makes it
worthless for any historical or long term evidentiary use.

The problem is that much of what also represents the events is the rest of
the row of data or the rows correlated or attached to it forming a larger
event structure. There is no legal difference in this type or report or in
an operator signing a printed report with a Digital Key. Legally they have
exactly the same value. So why then would I invest in or buy a TS Solution
that didn't add more to it.

What's missing is simple. As I have said many times in the past -

1)      In the existing RFC, the data about how the time data was obtained
and how it was managed so that in the future someone can look at TST's from
any number of sources and compare their validity or deviation from the
proscribed time source. This also means a audit model around the time base
itself. And it implies that the operator knows how to manage UTC in relation
to its soft value.

2)    A declaratory payload - something that can be used to indicate the
intent of the executor of the TST itself. That way going forward in the
future the Courts would not have to interpret that. And maybe other payload
types. Like the BERT Token for instance.

The other problem...
--------------------
In closing I would point out that the services of the PKIX time stamping
service can be had through NTP and perhaps some of Syslog too. And that as
such, this protocol is a piker. It pretty much does what the pre-existing
NTP and Syslog do together and based in that it violated the "no replicating
protocols that have been designed in other WG's" rule. OOOps.

What should have happened is that PKIX should of come up with something
other than a TST as a universal method of attaching time data to tokens or
other objects, something that could be used across all PKIX and a universal
Message Format for PKI based responses as well -  and this would have been
big win.

Instead we got what we got after 13 trips to the alter and the demise of the
Notary Draft in the process.

Todd

----- Original Message -----
From: "Jean-Marc Desperrier" <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, August 27, 2001 2:57 AM
Subject: Re: New test TSA available

>
> Peter Gutmann wrote:
>
> > But the token only allows one version value, v1, which is always present
anyway
> > (that is, it's a non-optional field).  Thus my earlier questions, that
there's
> > no way to indicate that you're using draft-n because it's assumed
there's only
> > one version, v1, as per the final RFC.  That means that anything from
> > draft-....-01 through to RFCxxxx can only indicate use of v1.
>
> A draft is just that, a draft.
> " It is inappropriate to use Internet-Drafts as reference
>    material or to cite them other than as "work in progress"
> And basically, you want them to become reference material.
> There isn't, and hasn't to be a formalism for interoperability between
versions of
> a draft.
>
> What is needed is a finalized version of this protocol in an RFC, so that
_this_
> becomes a reference, and something one can actually use for
interoperability.
> As long as this doesn't exist, the tokens can't be anything more than
laboratory
> experiments.
>
> Therefore the true question is why is this RFC still not there when
supposedly the
> draft is on the last stages of approval since monthes, and there hasn't
been any
> point raised about it in this mailing list since a long time ?
>
>

---

From: tho <[email-masked]>
Date: Tue, 4 Sep 2001 10:26:29 +0200

hi todd,
   
> types. Like the BERT Token for instance.

i think that these two points should be a matter of policy (and corresponding
practice statement) for which we have a pointer inside the TSTInfo

tho
--

---

From: Jean-Marc Desperrier <[email-masked]>
Date: Wed, 05 Sep 2001 10:47:09 +0200

Jean-Marc Desperrier wrote:

> What is needed is a finalized version of this protocol in an RFC, so that _this_
> becomes a reference, and something one can actually use for interoperability.
> Therefore the true question is why is this RFC still not there when supposedly the
> draft is on the last stages of approval since monthes [...]

I did not stand corrected about this point by anyone in the mailing list.
Surprising.

The TSP RFC is indeed issued now :

http://www.ietf.org/rfc/rfc3161.txt