[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dss] Updated nested renewed timestamps
Dimitri, A few specific comments: 1) 3.1.1 Server Support for <RenewTimestamp> is optional. So: The timestamping specific optional input <RenewTimestamp> MAY also supported and may be sent by the client. 2) 3.2.3 I would use the same word "supported". So: "and the server is able to process it" -> "and it is supported by the server" Also, I would start the sentence "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." on a new paragraph. 3) The definition of Timestamp Token in the Core spec 5.1.1 needs updating to allow several objects to be in <ds:reference>. Also, the proposed text for 3.2.3 could be made clearer by adding to the middle of the sentence as indicated in CAPITALS "An additional <ds:SignedInfo>/<ds:Reference> REFERENCING THE <DS:OBEJCT>/<DSS:PREVIOUSTIMESTAMP> must be included in the signature of the new timestamp signature" 4) 4.1.2 This is only true if <PreviousTimestamp> is supported by the server. Also this is written in terms of what the client may do. This is described in a very long sentence that is very difficult to understand. It is not very clear that T1 is the time in a renewed timestamp and T2 is the time value in the <PreviousTimestamp>. Can you have another go at this sentence. 5) It is not very clear that this an optional extension to the basic time-stamping profile. Particularly with verification, how does th cleint know whether the server is checking any <PreviousTimestamp> I suggest that this would be much clearer if this was defined as a Profile which is defined in the same document. Nick > -----Original Message----- > From: Dimitri Andivahis [mailto:dimitri@surety.com] > Sent: 04 April 2005 13:39 > To: dss@lists.oasis-open.org > Subject: [dss] Updated nested renewed timestamps > > > > Action 05-03-21-2: Dimitry update optional nested timestamps > extension to > > time-stamping profile (revision to action 05-02-28-03) > > Attached is the updated proposal for the nested renewed timestamps > based on some input from Nick. Only the contents of sections > of the timestamping profile affected by the track changes > have been included in the attached Word document. > > The previous timestamp is now specified in the new XML timestamp > as an additional <ds:Signature>/<ds:Object> element of the newly > generated timestamp, that is, as a sibling of > the <ds:Signature>/<ds:Object> containing the <TSTInfo> > (as opposed to as a sibling of <TstInfo> within the same > <ds:Signature>/<ds:Object> in the earlier proposal). > Thoughts requested on whether this is compatible with the current > text in Core Section 5.1.1 (XML Timestamp Token). > > Dimitri >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]