RE: [dss] ANSI X9.95 and timestamping profile

[Trevor Perrin <trevp@trevp.net>]

Hi Dimitri,

I like having the timestamp profile concrete, with almost no options so 
interop is easy.  If we add options that only certain time-stamp types 
support, it becomes more abstract.

So if timestamp-renewal is generic across different time-stamp 
technologies, it may be worth adding.  If not, I would leave it to be added 
by a sub-profile that extends the time-stamp profile.

(Also, why do people want Russian-doll structures of timestamps containing 
time-stamps?  Is this commonly done?)

Trevor


At 06:11 PM 1/21/2005 -0500, Dimitri Andivahis wrote:
> > -----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