|
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. |