Subject: Basic Event Representation Token (BERT)

From: Michael McNeil <[email-masked]>
Date: Fri, 06 Aug 1999 08:34:03 -0700

It's become apparent from comments made at the BERT presentation
in Oslo, others on this list and some received via e-mail that
the purpose and design of Bert aren't well understood within pkix.
I'll briefly try to clear up at least some of the misunderstanding.

One source of confusion, admittedly, was due to my use of slides
in Oslo which, as an example usage of Bert, illustrated a hardware
implementation.  To repeat what was said at that session, those
slides show an example of an application using the Bert Token --
one illustrating a physical situation where fine granularity timing
(much below the second level) might serve a purpose -- and thus a
timestamp format supporting finely grained timing is desirable.

What Bert is is a whole-cloth alternative to the proposed Time Stamp
Protocol (TSP), which can as readily be operated by a trusted third
party down a network remove as by a trusted piece of hardware within
one's own computer.  (Bert is _not_ a TST, the discussion of which
continues on the list, though Bert incorporates a variety of TST
within it -- which, I suggest, for compactness relative to the data,
ought to be the UTC96 representation described in the Bert draft.)

A key difference in the design of the Bert Token versus the Time
Stamp Protocol, as we see it, is that the TSP was clearly designed
with electronic versions of old-style paper documents in mind --
a model which inherently assumes a rather measured pace of
timestamping transactions (contracts to be notarized passing before
a notary public, for example).  The very existence of the discussion
on the list regarding whether granularity of time smaller than that
of a second ought to be supported is proof of that, in my view.

Bert, on the other hand, was designed with _computer_speeds_ in
mind.  Its intent is to enable "events" to be timestamped -- which
might involve, e.g., timestamping cascading crashes of multiple
computer systems being attacked by a worm, say, over a network.
"Events", in other words, which may require timestamps with small
fractions of a second resolution in order for those performing a
post mortem on the involved systems to put the recorded events
into proper chronological sequence, and make sense of them.

Another requirement for Bert is to allow individual transactions to
databases to be timestamped -- with a view of making such databases
inherently non-repudiated.  Since typical transactions to databases
involve a few hundred to a few thousand bytes of data, it's very
important that the timestamp (Bert) be as compact as possible --
no more than a few hundred bytes in length itself, so the addition
of non-repudiation timestamps to the data doesn't vastly bloat the
sizes of legacy databases.  Bert is very compact, in other words.

And yes, _some_ of the applications of Bert might involve hardware
running within a given computer host, rather than an at-network-
remove third-party-run Time Stamping Authority.  In no way, though,
does this mean Bert has particular ties to any vendor's hardware.
 
Regards,
Michael McNeil