RE: [dss] Timestamping

[Trevor Perrin <trevp@trevp.net>]

At 06:09 PM 4/4/2003 -0500, Dimitri Andivahis wrote:

>Trevor,
>
> > -----Original Message-----
> > From: Trevor Perrin [mailto:trevp@trevp.net]
> > Sent: Thursday, April 03, 2003 2:55 PM
> > To: Dimitri Andivahis; dss@lists.oasis-open.org
> > Subject: RE: [dss] Timestamping
> >
> >
> >
> > Dimitri,
> >
> > thanks, this is helpful.  Some questions/comments:
> >
> >   - I think I understand aggregation of A values into an
> > aggregated value,
> > and the simple linking of these aggregated values.  I don't understand
> > "accumulated linking", though.  What's the rationale?  How
> > exactly does it
> > work?  When you say that the TSA 'maintains recent A and S
> > values, as well
> > as the A and S values corresponding to the reduced subsequence of
> > timestamping "rounds"', I don't understand the phrase 'reduced
> > subsequence
> > of timestamping "rounds"'.
> >
>
>I think the authors of the accumulated linking techniques
>were mostly interested in providing optimal results for
>the length of proofs for relative temporal ordering amongst
>linked tokens.  A commercial system implementing such techniques
>exists, but I don't know specific details about it.
>
>Accumulated techniques are a bit hard to describe in short form.
>My novel term "reduced subsequence" is probably not a very successful
>one and I'm sorry if I confused you.  Accumulated schemes
>encapsulate the linking and publishing process in the same
>general linking scheme, instead of using one scheme for
>the linking process and a different scheme for publishing.
> From far away, it almost looks like a two-layer chaining,
>the top layer being the values for "rounds", and the layer
>below containing the sub-chains of the detailed linking steps.
>A token is cryptographically bound both to the sub-chains and
>to the published values for "rounds".  Different types
>of verification may be available for these different bindings,
>and the assumption is that it is easier to perform verification
>of the bindings to the "round" values.  The values for "rounds"
>are supposed to be published widely, and are always available
>online with the TSA.  The sub-chains between the values for "rounds"
>remain online for a while, but may be retired to deep storage
>or offline as they age.
>
>There are some advantages with these methods from a practical point
>of view, mostly in the reduced number of values that are kept online.
>On the other hand, disk space limitations are not what they used
>to be six years ago :)  These techniques do require a return trip
>to the TSA to bind the token to the subsequent "round" value
>(the token already contains a binding to the previous "round" value
>when it gets issued).
>
>I hope this helps with your questions some.

Thanks, I think I understand.  Is there a paper on this?



> >   - You mention a client getting a timestamp from a TSA, which can be
> > verified by running a verification protocol with a TSA or other
> > authorized
> > 3rd party.  In this case, a client who wanted to verify a timestamp would
> > only need to read the time from the timestamp, and enough identifying
> > information to know which verification service to contact.  The client
> > could treat the evidence (i.e. the BindingInfo data) as opaque.  So maybe
> > our timestamp data format should be something like:
> >
> > <TimestampData>
> >
> >    <Time>
> >      <!-- An indication of the time -->
> >    </Time>
> >
> >    <IssuingTSA>
> >      <!-- URI of issuer, if exists -->
> >    </IssuingTSA>
> >
> >    <VerifyingTSA>
> >      <!-- URI of a verification service, purely informative; may occur
> > multiple times -->
> >    </VerifyingTSA>
> >
> >    <Evidence Type = "http://www.oasis.org/dss#SomeTimeStampType">
> >      <!-- Linked/aggregated/accumulated values and so on -->
> >    </Evidence>
> >
> > </TimestampData>
> >
> > Then it could be left to follow-on work (maybe even a later document from
> > this TC) to define different <Evidence> types?  This is similar to what
> > Karel's paper suggests, except his paper goes further in
> > describing generic
> > structures that can be used with all different linking schemes.  That's
> > probably how things should be done eventually, but it seems
> > complex enough
> > that we should work on the core protocol first, and just make sure it can
> > be extended in the future.
> >
> > Trevor
> >
> > ...
> >
>
>I think Karel's document provides a lot of material for the necessary
>XML elements.

I agree.  Still, it's complicated.  I think we should make sure our 
timestamps can be extended to linking schemes in the future, but not 
support them explicitly in version 1.

Trevor