RE: [dss] Timestamping

["Dimitri Andivahis" <dimitri@surety.com>]

Trevor,

> -----Original Message-----
> From: Trevor Perrin [mailto:trevp@trevp.net]
> Sent: Thursday, March 20, 2003 10:50 PM
> To: dss@lists.oasis-open.org
> Subject: RE: [dss] Timestamping
> 
> [...] 
> 
> >Gregor's submission goes a long way towards providing support for it.
> >We would need to define a protocol for timestamp-token verification,
> >similar to what's done in ISO 18014-1.  I am offering to 
> contribute to any
> >additional work this may require.
> 
> It defines an XML format for linked timestamps.  But what are the 
> protocol 
> requirements for a linked timestamp service, above and beyond those 
> required for a "simple" timestamp service (i.e. one that just signs the 
> hash and time)?
> 
> For example, suppose the aggregation round lasts longer than the 
> client is 
> willing to wait to get his timestamp.  Does the client get a ticket or 
> something, and come back later to retrieve the finished product?  Doesn't 
> the service need to broadcast the aggregation round values, in such a way 
> that 3rd parties will archive them and they won't be tampered with?  Does 
> that require another data format and protocol?  And won't a 
> verifying party 
> need a protocol to retrieve these round values from the 3rd parties?
> [...]

The only protocols defined in the ISO documents are the 
timestamp request protocol and the timestamp verification protocol.  
No additional protocols specific to linked timestamp tokens
were defined.

The timestamp token issued by a TSA using linking methods 
contains the usual data (hash, time value, policy ID, serial number
and so on).  In addition, it includes the TSA name, and encapsulates 
the linking data needed for verification (BindingInfo).

Aggregation of timestamp token requests may be performed according 
to the TSA policy, for example every 500ms or after at most 512 
new timestamp requests have been received, whichever comes first.
According to 18014-3, aggregation is viewed as a way for the TSA 
to scale up its throughput, so no additional protocols were 
defined for "come-pick-it-up-in-an-hour" type of messages.
Aggregation is not necessarily the same as a timestamping round
the way the latter term is sometimes used in the literature.  
18014-3 makes no assertion about the ordering of the timestamp 
requests processed in a single aggregation operation 
(i.e., the TSA could have reordered them according to his fancy), 
while some of the papers describing algorithms using timestamping 
rounds make assertions about the ordering of the requests 
within a given round.

Freely paraphrasing from 18014-3:  
All timestamp tokens generated by an aggregation operation 
shall contain the same time value.  The TSA shall maintain 
a repository of the linked values resulting from each aggregation 
operation.  This repository is used for the verification of the timestamp 
tokens issued by the TSA.  The integrity of the repository 
is ensured by requiring that the TSA publishes in a timely fashion 
values derived from the repository of linked values computed above; 
different publishing schemes are recommended.  All communications 
between a requestor/verifier and such a TSA shall be over a data 
integrity and origin authentication protected channel.

Dimitri