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

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

Juan Carlos,

The main benefit of having the timestamp structure act as a 
container when you re-timestamp the data is ease of maintenance: 
you only have one object (the nested timestamp) associated with 
the timestamped data, and you may treat the original timestamped 
data in a read-only mode.  The procedures for requesting 
the renewed nested timestamps and for verifying them
are exactly the same for any type of timestamped data
and for any application.  There is no need to use container 
facilities specific to the data being timestamped 
(CMS or XML signatures, PDF documents, Word documents etc.)

To recap the proposal: 
re-timestamping the data AND an existing timestamp
is achieved by calculating the hash value on the data 
and by sending this hash value, as well as the existing timestamp,
to the server.  The server returns a new nested timestamp 
(with a current time value) that covers 
both the submitted hash value AND the submitted timestamp, 
and contains the submitted timestamp.

Having a single nested timestamp token for the timestamped data 
makes life extremely easy in document management systems, 
for example, if the timestamp tokens represent a single column 
in a database table referencing various types of documents.

Dimitri

> -----Original Message-----
> From: Juan Carlos Cruellas [mailto:cruellas@ac.upc.edu]
> Sent: Tuesday, February 08, 2005 5:56 AM
> To: Nick Pope
> Cc: Juan Carlos Cruellas; Dimitri Andivahis; dss@lists.oasis-open.org;
> Trevor Perrin
> Subject: Re: [dss] ANSI X9.95 and timestamping profile
> 
> 
> Nick,
> 
> As I was not present in the last meeting (appologize for that)
> I have not have the occassion of hearing about the rationale
> behind the need of time-stamping a time-stamp and I am
> not very sure of its need, but concerning to the
> proposals made I would say that the first option suggested by Dimitri
> would not require change in the structure of the time-stamp,
> as it is only a new ds:Object to be added to the ds:Signature,
> and it could even be profiled in a profile....
> The second one would require, for instance, add an extension
> mechanism to the dss:TSTInfo allowing any additional content that
> could be profiled in a profile... but this would imply to change
> the core with this new element
> 
> Juan Carlos.
> Nick Pope wrote:
> 
> >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
> >>
> >>
> >>
> >>    
> >>
> >
> >
> >
> >---------------------------------------------------------------------
> >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
>