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

["Nick Pope" <pope@secstan.com>]

Dimitri, Trevor,

This technique has been proposed as a mechanism for long term archival of
electronic signatures.

Could this sub-profile be added to the time-stamping profile document.

Nick


> -----Original Message-----
> From: Trevor Perrin [mailto:trevp@trevp.net]
> Sent: 24 January 2005 10:11
> To: dss@lists.oasis-open.org
> Subject: RE: [dss] ANSI X9.95 and timestamping profile
>
>
>
> 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
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dss-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: dss-help@lists.oasis-open.org
>
>
>