OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dss message

[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]