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

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

Juan Carlos,

My comments inline.

> -----Original Message-----
> From: Juan Carlos Cruellas [mailto:cruellas@ac.upc.edu]
> Sent: Friday, February 04, 2005 4:00 AM
> 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....


Actually, the "timestamp renewal" operation as defined 
in X9.95 and ISO/IEC 18014 is a re-timestamping operation 
over the original document (plus, over the previous 
timestamp, possibly nested).  It isn't just a operation 
over the previous timestamp alone.  For example, the new 
timestamp may be over a different <DocumentHash> element 
for the same document, and the document itself may be any
type of data (signed, unsigned, PDF, doc, etc).
In the case of XAdES, the document of interest is a digital
signature, and there is a similar concept with the use 
of archive timestamp(s) folded into the updated signature. 

> 
> 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?.
> 

That's right.

> 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.
> 

I tend to agree with your thoughts.

> Regards
> 
> Juan Carlos.
> 

Take care.

Dimitri

> 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
>