Subject: The BERT token and the our API services for it

From: "tog" <[email-masked]>
Date: Sat, 7 Aug 1999 08:01:59 -0700

All,
to clarify a point in Michael McNeal's mailing yesterday where he
essentially announced that we (Glassey-McNeil Technologies) intend to
release a complete API and protocol use model for our BERT token
structure...

It is pivotal to our thinking that the centerpiece of the timestamping
system be the Token Structure and not the routines or API that uses or
manages it. Our vision is that this token (aka 'the BERT')  is the only
really necessary point of interoperability in timestamping systems and that
the rest of it, that is the services and the tools that support the token
structure use models, are essentially an Application Level Technology API.

In addressing this vision, our intent was to create a simple lightweight
token structure that could easily be used for timestamping network events as
well as whole-cloth document services, and that could sit in PKIX as a
datastructure for representing time data and its validity (source,
resolution, indemnity statement, etc). Additionally we realized that
Jurisdictional Indication would be an important factor in sighting and
fixing events in time and space.

As to the issues facing timestamping on a global basis, there were
international ramifications as well, we figured that it might be a nightmare
to get systems standardized whole-cloth across International boundaries, and
that the token itself was a much simpler proposition.

We also looked at commercial proofing requirements and what they actually
provided vs. what they cost to operate, and we found that in distilling the
envelope of trust in question, that the perimeter OS in most instances was
exactly this envelope. This has many serious implications regarding the what
and the how of timestamping.

Another cornerstone of our vision is that it is irrelevant  whether the TS
service is operated externally, as a trusted third party, or internally as
underlayment for existing processes. That there is also a dramatic need for
this service model to be as fast as possible, as Bill Lattin noted so well,
technology is evolving and that is an important factor in any standard we
propose here.

With all of these issues in mind, we looked at BERT's use models and thought
it through pretty carefully. The BERT can be made smaller by replacing
literal content with OIDS and this can be done in a number of places.
Realize however, that this means that the token structure itself will not be
able to represent an event without other TRUST DATA external to the token
structure, in this case the OID Definitions. This externalizing the trust
components changes to totality and value of the trust processes being
supported. In these models the timestamp token leverages more reliance on
the routines that made and manage the tokens so they are similar in this to
the current TS Drafts.

Likewise for document or larger operations, the BERT can balloon up to 65K
now and can be chained together to support timestamping individual objects,
pages or whole documents.  There is also an optional token structure coming
in the BERT 2.0 draft that provides for adding a descriptive statement as to
the intent of the timestamp itself in the form of  an ESP. We feel this is
absolutely critical in building stamps that stand on their own two feet.
Likewise this "indicated intent statement" will support an external OID
representation of a statement of intent as well.

Back on the metal - the original BERT was designed to represent events in
time and space and to be essentially a  'totality of the event'
representation method. It is light enough to be used inside of both DB and
Warehousing Operations and strong enough to withstand any reasonable attack
of its' event.   In comparing BERT to other systems that use external
representation systems, that is to say systems that are not part of the core
application to represent their respective proofs,  BERT is based in a use
model for commercial trust processes, not absolute trust.

BERT systems are subject to attack in the OS just as all other systems are,
but TTP models or other BCP techniques limit these in day to day operations.
So the BERT is built for commercial grade proofing models and by leveraging
these against one another it eliminates the need for complex and expensive
to operate, external systems. The BERT based timestamping process can easily
run inside or as a local service to the application that needs it.

As to operating BERT systems themselves as TTP's, this works fine and
provides all the protection that an external site or TTP provides by its
relation to its customers. The idea is that the BERT work is all done
locally and then submitted to the auditor station for restamping and
logging, whether this is local or remote. This model, running an external
logger, actually can provide two (or more) separate timestamps for the same
physical event, and since the BERT API's timebase, resolution/reliability
data is included with the BERT Token, they - the events referenced and
proven by the tokens - are directly comparable to each other, even when they
are created thousands of miles or years apart.

Regarding the current TS and DCS services. The BERT API is another competing
system for timestamping, the BERT token is not. There is no reason why the
BERT Token could not easily be a TST.

In closing I want to mention personally that I believe that the BERT is a
much simpler solution for the standards process than a fully blown system
and pretty much, any API that implements the BERT to be commercially valid
will just need a simple audit, not the blessing of this committee. I also
want to say that either of the other two systems currently proposed for
issuing secure timestamps could easily interoperate with the BERT token
structure and that this would create a uniformity that would provide
reasonably any service model to be supported.

BERT is also not cast in concrete, if you have any additions or suggestions
lets run them up the flagpole so to speak!

Todd Glassey