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

[Trevor Perrin <trevp@trevp.net>]

At 01:28 PM 1/27/2005 -0500, Dimitri Andivahis wrote:
>Trevor, Nick,
>
>This method can be used to assert integrity and time of existence
>of a document in long term archives, while at the same time
>it maintains a clear distinction between the document itself
>(possibly containing electronic signatures) and the collected
>timestamping information about it.  Renewing a timestamp token
>for a given document results in a newly generated timestamp
>token that takes the place of the previous timestamp token.

I understand the point of re-timestamping a document.  I'm just not sure 
why you'd want the new timestamp to encapsulate the old one.


>This method has been included in ANSI X9.95, ISO/IEC 18014-2,
>and ISO/IEC 18014-3.
>I expect it will be practiced by vendors who
>follow these standards.

I dunno, "expect" sounds like you're still waiting for people to use it :-)



>If the types and processing rules for supporting the renewal method
>in XML timestamp tokens are defined with some care, it can allow
>for a mix of any XML timestamp token types in the "Russian doll structure".

I'm just not sure it's worth the effort to "define with some care" such a 
minor feature (effort to write new text, for the group to review, for 
readers of the document, and for implementors).  Especially at this date, 
and especially cause the time-stamping profile is minimal and generic in 
spirit.

I'd rather have someone do this in a sub-profile if they want.


>There are different possible ways to implement this method within
>the DSS timestamping profile.  One possibility that agrees well
>with the protocols in ANSI X9.95 is to specify the previous token
>in a sign request via a new optional input such as RenewTimestamp:
>
><xs:element name="RenewTimestamp">
>   <xs:complexType>
>     <xs:sequence>
>       <xs:element ref="dss:Timestamp">
>     <xs:sequence>
>   </xs:complexType>
></xs:element>
>
>that carries the previous timestamp token.


That would work, you should propose it at the meeting and we'll get the 
group's consensus.

Trevor



>The service generating the renewal token need make no assertions
>about the validity of the previous token submitted to it.  The client
>must verify that the previous token matches the document(s) of interest,
>and the client should verify that the previous token is presently
>valid at the time of renewal.
>
>For XML processing rules for <ds:signature>, if this optional input
>is present, the service must include the previous token as
>the second child element of <ds:Signature>/<ds:Object> in the
>generated renewal token and cover it with the signature.  Currently,
><TstInfo> is the only specified child element of <ds:Signature>/<ds:Object>.
>[Alternatively, we could update the definition of the <TstInfo> type
>and add the previous token as a child element of <TstInfo>.
>This would keep all information about time values within <TstInfo>
>and would be more in line with the claim that the time value
>in the innermost token is the asserted value of existence.]
>
>For CMS processing rules, it would be best to let sub-profiles
>specify a solution that is appropriate for their needs.  For example,
>CMS services compatible with ANSI X9.95 may or may not require that
>the submitted previous token be an ANSI X9.95 compliant token,
>and they would place the previous token as an extension within
>the CMS TSTInfo structure of the newly generated renewal token.
>
>Services that do not support renewal requests would just return
>a NotSupported result code.
>
>For verify requests, the service need only verify the outer token
>and not deal with the inner previous token(s).  To completely verify
>a renewal token and assert the time value in the innermost (oldest) token,
>the client must access each successive inner token and submit
>for each one a verify request that also specifies the time of issuance
>of its immediately enclosing token.  To that effect, the DSS timestamping
>profile needs to allow the VerificationTime additional input in verify
>requests.
>
>Dimitri
>
> > -----Original Message-----
> > From: Nick Pope [mailto:pope@secstan.com]
> > Sent: Monday, January 24, 2005 5:34 AM
> > To: Trevor Perrin; dss@lists.oasis-open.org
> > Subject: RE: [dss] ANSI X9.95 and timestamping profile
> >
> >
> > 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
> > >
> > >
> > >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dss-unsubscribe@lists.oasis-open.org
> > For additional commands, e-mail: dss-help@lists.oasis-open.org