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

["Dimitri Andivahis" <dimitri@surety.com>]

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.

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.  It is general enough in scope that 
it could be applied to any type of timestamp token, and it can 
be used to support renewal of legacy tokens using XML timestamp tokens.  
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".

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.

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