RE: [dss] Updated nested renewed timestamps

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

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 
>

Snippet.doc