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

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

Juan Carlos, Dimitri,

I would prefer to avoid changing the TSTInfo structure just for this
requirement.  It would be preferable to use an approach which can be handled
using the existing extension mechanisms.

Nick

> -----Original Message-----
> From: Juan Carlos Cruellas [mailto:cruellas@ac.upc.edu]
> Sent: 04 February 2005 09:00
> To: Dimitri Andivahis
> Cc: dss@lists.oasis-open.org; Nick Pope; Trevor Perrin
> Subject: Re: [dss] ANSI X9.95 and timestamping profile
>
>
> Dimitri,
>
> First of all a perhaps silly question...sorry if
> it actually is...
> Is there any rationale behind that advices to
> just renew the time-stamp instead re-timestamping
> the document or even generate a new time-stamp for
> both depending on the context or is it
> just a way of offering different alternatives to the
> market and let it decide?.
>
> Just as an example, in XAdES for instance,
> when we have to renew timestamps for signatures
> long term archiving, we generate
> a new timestamp that includes both certain
> elements of the signature itself and previously generated
> timestamps....
>
> Concerning the details on how to deal with the
> technicalities in XML....
> I have understood (but perhaps not correctly)
> you propose two alternatives:
> 1. To add the old token as the second child. So that you
> are sugesting to have a <ds:Signature> as the child of
> the <ds:Signature>/<ds:Object> just generated....
> So this would imply that each renewal of the time-stamp
> would imply increase the level of depth at which you would
> have ds:Signature corresponding to former time-stamps...
> Have I correctly understood it?.
>
> 2. To add the old token within the <dss:TSTInfo> so in the
> end, the most recently token would be a <ds:Signature> with
> a <dss:TSTInfo> that in its turn would have a <ds:Signature>
> with another <dss:TSTInfo> with another <ds:Signature> and so on
>
> Well, certainly the alternative 1 somehow makes visible at the
> level of the signature itself the details of the linking in time
> between the token and those previously generated. The second
> one just encloses these details within the <dss:TSTInfo>, and
> the management of all the information of previous tokens would
> be conceptually linked to the processing of <dss:TSTInfo>. I would
> say that if we go on with this work, I would be more in favour of
> this last one.
>
> Regards
>
> Juan Carlos.
>
> 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.
> >
> >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
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dss-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: dss-help@lists.oasis-open.org
>
>
>