Subject: The purpose of time stamping

From: "Jose A. Manas" <[email-masked]>
Date: Wed, 02 Jun 1999 07:56:36 +0200

Denis Pinkas wrote:

> 2° We are defining a Time Stamping Protocol that can be used in many dfferent
> contexts. We do not claim that it is usable in all the contexts. 

Sure you cannot, but nevertheless I think it is interesting to try
to cover as many scenarios as possible, or to be as general as feasible.

However,

> We have made a
> few *simple* extensions that were beyond the original goal, in particular to be
> able to answer to the simple question "What time is it ?" when the requester has
> no local time available. 

I don't see the point of using a TS protocol for any purpose that
excludes stamping. There are excellent protocols for finding out the
time
if you are on-line (e.g. NTP). An the point sounds very strange if your
were using the TSP off-line (e.g. batch time-stamping, e-mail exchanges,
etc).

> The primary need is only to prove that a digital
> signature was created before a given date. That digital signature may be any
> signature; e.g. from a user; from a CA for a user certificate,
> cross-certificate, CRL, ARL; from an Attribute Authority for an Attribute
> Certificate ... As there are too many examples of use, only a few are mentioned
> in the annex.

But when the protocol is restricted to signing a hash, the only thing
you
can directly prove is that the hash value exists when the time is
stamped.
I may infer that the hash value was generated before, as far as the
hash algorithm is not forgeable.
That sounds fine for building proofs of possesion of documents.

But with respect to signatures,
I find it strange that you carry along 2 tokens (e.g. the CRL itself and
its
detached time-stamp). If I were the user of the certificates, I'd ask
for a reliable time of issuance in the same pack.
In electronic commerce exchanges, I want the committments singed and
time-stamped, to be preferred in a single token.

> 3° The protocol is sufficient for our current needs. Thus I do not see the need
> to extend the terms of reference of our charter to cover more.

Shall I understand that if other business needs are identified for
time-stamping, a new protocol is needed?
I think it is a pity that standards are too focused towards current
needs.

> Regards,
> 
> Denis
> (co-author of the current draft)

pepe
[just thinking aloud]

-- --------------------------------------------------------
Prof. Jose A. Manas                     <[email-masked]>
Dpt. Telematica                 http://www.dit.upm.es/~pepe
E.T.S.I. Telecomunicacion           tel: [+34] 91 336 73 25
Ciudad Universitaria                gsm: [+34] 607 73 38 94
E-28040 Madrid, SPAIN               fax: [+34] 91 336 73 33

---

From: Stephen Kent <[email-masked]>
Date: Tue, 8 Jun 1999 19:36:07 -0400

Todd,

It's been a couple of weeks since you sent this message, but it still
deserves a response:

>I respect and appreciate your accomplishments but I think you dead wrong
>here and everything I have had to live through for the last two years tells
>me I am right.  My issue in saying this publicly is that "Stephen Kent" is a
>name that carries a lot of weight when it is attached to an opinion, which
>is why I am so baffled as to your resistance to building in these proofing
>facilities into the timestamping process.

I always try to avoid ceating standards that rely on a particular
technology for which there may be intellectual property issues, or which
seem to define a problem to solve, irrespective of real needs.

>It seems to me that what we are focusing on here is an elaborate mechanism
>to pass relative time through a distributed infrastructure, rather than the
>real goal - that being to have a system for representing events in time that
>is accurate, believable, and commercially viable.  Mark the phrase
>"Commercially Viable", because it is the key to any market success we will
>have unless someone puts a law in place to mandate our products.

Commercially viable timestamping takes place today in a variety of forms,
most of which have no need for high precision or high accuracy.  In the
physical world we time stampt with rubber stamps to the granularity of a
day, and with electrical time spamts with a minute granularity, both with
questionable accuracy.  What I sense in many of your postings is a belief
that "commercial viable" requires much different assurances and
accuracy/precsion guarantees.  What I asked for in a previous message was a
coherent discussion of the requirements, without any marketing fluff.  I
have yet to see such a discussion.

>Personally, I am starting to want to call this timestamping protocol the
>Bradley Fighting Vehicle of the PKIX group - ever see Kelsey Grammer in
>"Pentagon Wars" - and although I know that is not true, it's sorta how I
>feel about all the abuse I have taken for questioning the use and
>architecture of this effort's end goals.  The ultimate reason for my
>responses here is driven in the simple economic fact that if I have to shell
>out money for this technology, it better pay me back somehow.

I eon't claim that we can't do better, and maybe we will make a clean start
on this if there is a concensus on that.  Howeverm you should know that
IETF WG development of standards is often an arduous process that sometimes
reuqires compromises, while we do strive to achieve technical elegance.

>As to your commentary particular that "it's not there" below, that is to
>say, the ability in the protocol to prove the chain of custody against the
>time source - I know it's not there and I am trying to figure out why.

Maybe because the WG does not believe that we need it.  Again, I'm waiting
for the technical rationale that justifies such added complexity.

>What I think we have built here today is a system that requires the user or
>operator to jump through external hoops to prove the process and model of
>operations at the sites are OK, otherwise the timestamps issued are of
>questionable veracity and as such there use and reception are likely to be
>limited.

In working on various aspects of "the PKI problem" for the last decade,
many of us have found that it is very hard to create self-contained systems
that operate independent of external assurances, and it may have just been
a bad idea from the start.  Businesses usually engage in bilaterial
agreements with one another or with clients prior to doing business in the
physical world and tryign to create PKIs that avoid the need for such
argreements has probably caused us to have less PKI deployment over the
last 5-10 years.  I would not like to see a similar assumption about time
stamping cause similar problems in this arena.  I think we differ in our
perception of what is needed to make this "work."  I am willing to be
persuaded by suitable arguments, but I've yet to see them, hence my
resistance to efforts to steer this work in the direction you suggest.

>As to the existing draft's specification, my problem is that I have still
>not figured out a legally binding model for a large enough segment of the co
>mmercial world to use this timestamping technology, that this makes
>commercial sense.

This is exactly the sort of argument that I find frighteningly parallel to
the PKI work we've been doing.  Folks have insisted that if we must create
PKIs that will stand up in court when a party tries to repudiate a
signature for a zillion dollar transaction.  Experience has shown that this
is just wrong, and we have seen many examples that support the notion of
limited scope PKIs that provide sufficinet benefit to warrant their
deployment.  I believe that the same will prove true here, and I've yet to
see cogent arguments otherwise.

>DONT GET ME WRONG - I AM NOT TRYING TO TELL YOU THAT THE ZUCCERATTO, et al.
>DRAFT IS BROKEN, just that I want to understand the use models driving all
>this effort in detail.

How about a use model in which a company internally timestamps documents in
an analogous to the wahy in which they used to manually time stamp them.
Workstations throughout the company send hashes of documents to the TSA and
get back appropriate tokens. The TSA could be local to the company, which
would be analogous to what was done manually before.  The assurances that
the TSA does not have it's time changed inappropriately will vary,
depending on the TSA implementation, just as controls for physical time
sources vary considerably in different application environments today.
Even if there is a need here for the company to be able to establish the
source of the time used by the TSA, there is no rerason, a priori, that
this "proof" be available except to an auditor.

Your call for a standard based on a "chain of custody" model sound like
what we would have if we required all PKIs to be very high assurance, e.g.,
users may employ only smart cards, CAs may use only FIPS 140-1 level 3/4
crypto modules, CA software will execute only on a suitable trusted
computing base, ...  We don't require this sort of environment for a
PKIX-compliant PKI, nor have we skewed the standards in any way to better
support such high assurance PKIs.  We do provide for a policy OID in a cert
that allows a CA to state the context in which it issues certs.  Thus it
seems consistent that we support the same sort of infrastructure assurance
labelling here.

Steve