Subject: The rewritten opening statement and some thoughts on the goals!

From: "todd glassey" <[email-masked]>
Date: Tue, 24 Oct 2000 10:26:54 -0700

Hi all - and Denis,
I figure this will start several small brush fires and that is not my
intent. So I apologize to the group at the outset - but let me share a
bizarre concept with you - 'We humans are the problem, not the answer with
Digital Evidence Models' and by using Time Stamping digital trust operators
are supposed to address this.

Digital Evidence models are made weaker by having to have humans testify as
to their validity. Its a simple concept.  You see machines don't have any
consciousness, so they cant "lie" per se, but we as humans can, and do - all
the time. So any proofing model that does not include methods of abstracting
its reliability away form "Human Reliance" is broken (IMHO) and that is
really that.  What I think that this means is that the Time Stamps that are
produced by such a system have no way of separating themselves form the
system they were created on or the people that ran that system, and this is
the key flaw to the big picture.

And as long as I am talking about qualifying the parametric data the TSP
uses, we need to have a new document, a timing practices statement added to
the trust model.  This defines the proofing models for where the time data
came from, and needs to be a part of the evidentiary trail and since the
draft ignores the concept of  a Timing Practices Statement.

So I suggest something like the following to clean up the opening
statements:
-------------------------
Digital evidentiary models require that digital events have some a method of
stipulating the time in which a digital event took place. These models also
require the ability to be run in computers unattended as part of a larger
audit process and proofing system. Because of these emerging requirements,
this Draft proposes a distributed method of associating time and event data.
This document then describes this complete protocol  to provide this
Distributed
or TTP based Time Stamping.

The facility of the TSP provides a proofing process to demonstrate that a
digital
event  occurred or existed as per the policies of the Authority running the
Time
Stamping (TS) System.  Thus it can be used to satisfy both policy based
decisions
as well as stand for producing a basic level of evidentiary content. The TS
Draft
defines the infrastructure or format of a request  sent to a  Time Stamping
Authority
(TSA) and of the response that is returned. It also establishes several
security-relevant
requirements  for TSA operation, with regards to processing requests to
generate
responses.

The protocol defined herein is envisioned to be typically operated as a
Trusted Third
Party (TTP,  but its protocol (or API) may be implemented as an embedded
system
to address  single platform use of a time stamping.

< and then the ISO NR words!>

Non-repudiation services [ISONR] require the ability to establish the
existence of data before specified times. This protocol may be used as
a building block to support such services. An example of how to prove
that a digital signature was generated during the validity period of
a public key certificate is given in an annex.