[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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 > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]