A couple points on the timestamping issues in the Core

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

Section "5.1.1 5.1.1 XML Timestamp Token" under paragraph 
"<ds:SignedInfo>/<ds:Reference> [Required]" went through 
the following phases:

===
wd-30.doc:
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.

wd-35.doc:
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.

wd-41.doc:
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.
===

I think we should revert to the version of the text in wd-35.doc.
As it stands now, nothing is being said about the XML timestamp
binding the input documents (data or hashes).

The other issue is, I would like the text to avoid referencing
exactly two ds:References in XML timestamps on signatures.  
The text in 3.5.2.2 should specify that the two <ds:Reference> 
elements must be present in the <ds:Signature> but not 
exclude other elements (it may already accept this 
interpretation, depending on the way you read it).  
The text in 4.3.2.2 should modify step 5 and instead specify 
that the two expected references be looked up and handled as described, 
and that any remaining <ds:Reference> elements be handled according 
to the specified profile or if XMLDSig rules.

Dimitri