[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dss] Nested renewed timestamps
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 > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]