Subject: The PKIX meeting...

From: "Todd S. Glassey" <[email-masked]>
Date: Mon, 19 Jul 1999 13:12:34 -0700

Stephen, 
I am sorry that I missed the Oslo meeting now more than ever when I read your report on the BERT session in the Meeting. We perhaps didn't make the value of vision of the BERT effort clear enough or convey its use properly, again my profound apologies, with that in mind, perhaps I can correct some of the micconceptions cited in your report.

The BERT Token and API Effort is borne from that McNeil and I wanted to create a common event auditing token that would give the App Designers and their users as much flexibility as possible. We have come to realize that for many application domains the audit trail itself "is the event token stream" and that it should stand separately from the system that produced it. 

The overall BERT Architecture provides just such a token structure to modularly represent events as per their proofing requirements. The idea is that there are a tremendous number of diverse PKI applications and use models and a number of them really need common points of interchange. We see this as the perfect use of the timestamp or watermark. 

Thankfully, the experiences of such development forums as the PKIX WG, the X.509 Groups and the ANSI X.9 efforts have all rolled some pretty good working infrastructure tools our way, and the missing pieces in the big PKI picture are now pretty much just the glue and studs to hold the systems together. However, as more and more business comes online so to speak, we see these in and of themselves are of more and more import.

For these 'glue and studs' we propose commercial users are more likley to want simple stand-alone timestamps rather than fully blown certs or any other complex PKI enabled structures - especially if the run closed network infrastuctures and their audit models are all internal. That is why we are focused directly on representing the event and then designing the method and process of securely creating the event token. We were sure that with relaible sources of time like the new secured NTP channels and Secured ACTS coming online, that BCP models that include securely setting the local timebase will be more likely to stand scurtiny, so with the timebase and its validity addressed in technical process, then the token structure becomes the point of exchange so to speak.

With regard to the BERT token and what it is, BERT is a data-blob that allows one to specificy events in time and 3-D space with an excellant level of precision.  The BERT token is extensible so that it can be adjusted to various size and proofing use models. The BERT Token is interoperable and can be represented in a number of formats including ASN.1, S/MIME, XML, and Binary. Not only that, we see no reason why a BERT token could not be a TST in the current TS Drafts. This is a basic design philosophy divergence from the current timestamping protocol drafts and that the timestamping system must allow for the token to contain time and jurisdicitional or intent conveyance payloads.

As to the delivery of the Protocol Spec to accompany the Token Structure Draft, the current Protocol/API Spec is still in a state of flux but should be out within the next 30 days I would hope. 

As to Datum's involvement and the IP issues, Datum is building a solution that we (McNeil and I) understand is based on their evolving some of McNeil's and my earlier work, and it is an excellent solution for an embedded timebase, but it is not BERT, lets be very clear on that. Lets also address the IP issues here. BERT's structure is available to use Gratis, under an GNU style license for commercial and noncommercial uses aleady up on the site at http://www.gmtsw.com/ietf/bert . Our API code is also to be available to non-commercial users under a similar license, but the BERT structure and its proofing models are very simple to use so rolling your own solution around BERT is a snap.

The point is that BERT is a good working solution for adding a common point of reference into legacy and new computing application models.

Todd Glassey
-----------------

Basic Event Representation Token (M. McNeil-GMT)
The author notes that this proposal relates to the TSP work, but uses what
is believed a more compact format so that it may be used in environments
where the size of the response from a TSA is too big.(1) The primary use model
provided here is rather implementation-specific, i.e., tamper-evident
hardware in a local context, vs. a TSA accessible via a network (2).  A
Security AD raised questions about any intellectual property claims
associated with this model, as this may affect whether the proposal is
appropriate for an IETF WG(**). The speaker stated that he is aware of no IP
with regard to the proposed formats, etc. A PKIX WG chair expressed concern
over the apparent product-specific nature of the proposed model (1).  The
author acknowledges that only one vendor (Datum) offers the sort of
hardware cited as the primary use example. The WG chairs and the Security
ADs will discuss whether this work is appropriate for PKIX, given the
issues cited above.