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

[Juan Carlos Cruellas <cruellas@ac.upc.edu>]

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
>