Nested renewed timestamps

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

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

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.

=======