RE: [dss] Updated nested renewed timestamps

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

Dimitri,

These changes are OK.

1) Regarding the placement of note in 4.1.2, I would suggest that there
should be an overview sub-section of section 1 which descibes time-stamping
in general as well as nested time-stamping.

I have put in the Roadmap document the following text on time-stamping:

"The Time-stamp profile define the use of the DSS Core protocols to support
creation and verification of time-stamps.  The profile includes support for
the creation of XML Time-stamps as defined in the Core and binary
time-stamps as defined in [RFC 3161]."

Which I suggest you out in a new section "1.3 Overview" along with
additional text on "nested" time-stamps.

2) I will forward the updates on the Core for Stefan to include.

Nick



> -----Original Message-----
> From: Dimitri Andivahis [mailto:dimitri@surety.com]
> Sent: 27 June 2005 23:01
> To: Nick Pope; dss@lists.oasis-open.org
> Subject: RE: [dss] Updated nested renewed timestamps
>
>
> Nick,
> Based on your suggestions I updated and attached the nested renewed
> timestamps document (track changes against the current timestamping
> profile document).  Detailed amswers below.
>
> > -----Original Message-----
> > From: Nick Pope [mailto:pope@secstan.com]
> > Sent: Monday, April 04, 2005 10:29 AM
> > To: Dimitri Andivahis; dss@lists.oasis-open.org
> > 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.
> >
>
> Agreed.
>
> > 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"
> >
>
> Agreed.  Similar update in 3.1.1.2.
>
> > 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.
> >
>
> Agreed.
>
> > 3) The definition of Timestamp Token in the Core spec 5.1.1
> needs updating
> > to allow several objects to be in <ds:reference>.
> >
>
> 5.1.1 Replace:
> ---
> <ds:SignedInfo>/<ds:Reference> [Required]
> There MUST be a single <ds:Reference> element whose URI attribute
> references the <ds:Object> containing the enveloped <TstInfo> element,
> and whose Type attribute is equal to
> urn:oasis:names:tc:dss:1.0:core:schema:XMLTimeStampToken.
> The remaining <ds:Reference> element(s) will reference
> the document or documents that are timestamped.
> ---
> with suggested text:
> ---
> <ds:SignedInfo>/<ds:Reference> [Required]
> There MUST be a single <ds:Reference> element whose URI attribute
> references the <ds:Object> containing the enveloped <TstInfo> element,
> and whose Type attribute is equal to
> urn:oasis:names:tc:dss:1.0:core:schema:XMLTimeStampToken.
> For every input document being timestamped, there MUST be
> a single <ds:Reference> element whose URI attribute references
> the document.
> [Note: Nothing disallows additional <ds:Reference> elements in
> <ds:SignedInfo>.]
> ---
>
>
> It may be that 5.1.3 step 7 needs to be updated for the less
> common case of
> multiple document hashes (independent of the current discussion):
> ---
> 7.	Verify that there is a ds:SignedInfo/Reference element
> whose URI attribute
> correctly identifies the timestamped document.
> ---
> Suggested text:
> ---
> 7.	Verify that each timestamped document is referenced by a single
> ds:SignedInfo/Reference element.
> ---
>
> > 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"
> >
>
> Agreed.
>
> > 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.
> >
>
> I updated my proposed text in 4.1.2, and hopefully made it clearer.
> I changed it to a Note (non-normative), since this is really
> a use case for nested renewed timestamps and for the
> <VerificationTime> optional input in a timestamp verify request.
> Not sure if this is the best location for it, an alternative location
> could be the end of Section is 3.1.1.2, neither is perfect.
>
> The server cannot check the validity of the timestamp within
> <PreviousTimestamp>.  There is no need for extra server side code
> that handles the <PreviousTimestamp> object when verifying
> XML timestamps of type <ds:signature>.
>
> > 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.
> >
>
> I think we covered this issue in a earlier phone conference:
> the verifying server cannot check the timestamp within
> the <PreviousTimestamp> element for validity, since the verification
> protocol specifies document hash value(s) for the outer signature only
> (the outermost timestamp).  The client must submit each contained
> timestamp separately to a server, along with the corresponding document
> hash value(s).
>
> A DSS server could verify all nested timestamps at once if it had
> access to the document (not acceptable in timestamping) or if it had
> access to all nested temestamp document hash values (not easy to fit).
> The most natural solution for this problem is a middleware component
> between the dumb client and the DSS server.
>
> > Nick
> >
>
> Dimitri
>
> >
> > > -----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
> > >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe from this mail list, you must leave the OASIS TC that
> > generates this mail.  You may a link to this group and all your
> > TCs in OASIS
> > at:
> > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
> >
>