Re: Comments on time-stamp-01: Identification of TSA

[Stephen Kent <kent@xxxxxxx>]

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