[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dss] Timestamping
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]