RE: [dss] Nested renewed timestamps

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

Dimitri,

A few thoughts on this:

> -----Original Message-----
> From: Dimitri Andivahis [mailto:dimitri@surety.com]
> Sent: 25 February 2005 21:47
> To: dss@lists.oasis-open.org
> Subject: [dss] Nested renewed timestamps
> 
> 
> > ACTION - 05-02-07-05 [Dimitri] Draft text for nested renewal 
> > timestamps, specify documents affected, and continue discussion 
> on the mailing list.
> 
> The following text contains the proposed changes to the 
> oasis-dss-1.0-profiles-timestamping-spec-cd document
> for the purpose of supporting nested renewed timestamps.
> 
> Dimitri
> =======
> 
> 3.1.1 Element <OptionalInputs>, Line 111:
> ----------------------------------------
> Replace: 
> 
> "No other optional inputs are supported."
> 
> with the following text:
> 
> "The timestamping specific optional input <RenewTimestamp> is 
> also supported. 
> No other optional inputs are supported."
> 
> 3.1.1 Element <OptionalInputs>, Line 112:
> ----------------------------------------
> Before current text, introduce subsection header "3.1.1.1 SignatureType".
> 
> 3.1.1 Element <OptionalInputs>, Line 118:
> ----------------------------------------
> After end of current text, add subsection "3.1.1.2 RenewTimestamp"
> and the following:
> 
> The <RenewTimestamp> optional input element indicates to the 
> server that the
> current sign request is a request for renewal of an existing timestamp on 
> data that were timestamped in the past, so that the validity 
> period of the 
> existing timestamp is effectively extended.  If this optional 
> input is present 
> in the sign request submitted by the client to the server, and the server 
> is able to process it, the timestamp element contained in this optional
> input must also be present as an element of the resulting timestamp 
> generated by the server and returned to the client.
> 
> <xs:element name="RenewTimestamp">
>   <xs:complexType>
>     <xs:sequence>
>       <xs:element ref="dss:Timestamp">
>     <xs:sequence>
>   </xs:complexType>
> </xs:element>
> 
> Note: Legitimate reasons to renew a timestamp include (a) the 
> public key certificate 
> used to verify the digital signature in the timestamp is nearing 
> its expiration date, or (b) the client needs to replace the hash 
> value used for 
> the timestamped data in the existing timestamp with a hash value using 
> a stronger hash algorithm.
>  
> Before submitting the sign request, the client must verify that 
> the existing 
> timestamp matches the document(s) of interest, and the client 
> should verify 
> that the existing timestamp is currently valid.
> 
> 3.2.3 Element <SignatureObject>, Line 133:
> -----------------------------------------
> Add after end of current text:
> 
> If the <RenewTimesamp> optional input is present in the sign request 
> submitted by the client to the server, and the server is able to 
> process it, 
> the timestamp element contained in this optional input must also 
> be present 
> as an element of the resulting timestamp generated by the server and 
> returned to the client.  Specifically, for XML processing rules for 
> XML timestamps of type <ds:signature>, the server must include 
> the timestamp element contained in this optional input as a child element 
> of the <ds:Signature>/<ds:Object> in the newly generated timestamp
> (in addition to the <TstInfo> already contained therein) and cover it
> with the signature.

Is there a need for a special type to identify the nested timestamp as being the <PreviousTimestamp>?

> 
> The server generating the new timestamp in response to a request 
> carrying the
> RenewTimestamp optional input need make no assertions about the validity 
> of the existing timestamp submitted to it within this optional input.
> A server that does not support the RenewTimestamp optional input 
> must reject 
> the sign request with a <ResultMajor> code of RequesterError and 
> a <ResultMinor> code of NotSupported.
> 
> 4.1.1 Element <OptionalInputs>, Line 137:
> ----------------------------------------
> Replace: 
> 
> "The client MUST NOT send any optional inputs." 
> 
> with the following:
> 
> "The client may submit the <VerificationTime> optional input to 
> instruct the server to determine the timestamp's validity at the 
> specified time, instead of the current time.  No other optional inputs 
> are supported."
> 
> 
> 4.1.2 Element <SignatureObject> , Line 139:
> ------------------------------------------
> Add after current text:
> 
> In the case where a timestamp T2 has been generated in response
> to a sign request carrying the <RenewTimestamp> optional input
> on data and an existing timestamp T1, and if the validity 
> of timestamp T1 can no longer be asserted independently, 
> (for example, because of compromised cryptographic primitives),  
> the client may assert the validity of timestamp T1 
> by submitting the timestamp T2 to the server for verification, 
> and by submitting the timestamp T1 to the server 
> for verification using the optional input <VerificationTime> 
> set to the time value indicated in timestamp T2.  
> This process may be generalized to multiple levels of nested
> timestamps.
> 

Guidance on how the relying party knows whether the time-stamp server has verified the nested time-stamp could be useful.

> =======
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dss-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: dss-help@lists.oasis-open.org
> 
> 
>