[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dss] ANSI X9.95 and timestamping profile
> -----Original Message----- > From: Trevor Perrin [mailto:trevp@trevp.net] > Sent: Wednesday, December 08, 2004 3:57 AM > To: dimitri@surety.com > Subject: Re: [dss] ANSI X9.95 and timestamping profile > > > At 06:14 PM 11/29/2004 -0500, Dimitri Andivahis wrote: > >The ANSI X9.95 timestamping document describes a process > >for a requestor to renew an existing timestamp token for a given > document. > >As part of it, the requestor submits a timestamp request to the TSA > >for the given document and includes (in a request extension) > >the previously issued timestamp token. The new timestamp token issued > >by the timestamping service encapsulates the previously issued timestamp > >token by including it in an extension of the TSTInfo. > [...] > > >I was wondering though if support for the mechanics of timestamp renewal > >should be folded into the timestamping profile itself, since it appears > >to be a generic enough operation for all types of timestamp tokens. > > A client can request a timestamp on some input documents which include an > older timestamp. So I think we already support that? > > > Trevor > Hi Trevor, Picking up the thread again after a very long break. I think that for a small price (the slight increase in size of the "renewal request" message and the resulting "renewed" token) there are some significant benefits in the way renewal is supported in the ANSI X9.95 document. Requesting a "renewed" token becomes a well-defined client side operation, as opposed to roll-your-own client transform over document and existing timestamp token as currently permitted by the DSS timestamping profile. The "renewed" token contains the previous token (and so on, recursively) for the associated document, which may simplify handling of tokens in application workflows. The "renewed" token can be easily stored as a single object detached from the accompanying document, which is a plus when timestamping non-XML data. The operations required on the client side for verifying the "renewed" token require dealing with the "outer" info (latest timestamping event) as well as the encapsulated tokens, but are a relatively straightforward extension of what's already defined for verifying a "simple" token in DSS. Dimitri
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]