W3C home > Mailing lists > Public > public-xmlsec@w3.org > April 2010

ACTION-345: "Review 2.0 sig docs"

From: Ed Simon <edsimon@xmlsec.com>
Date: Thu, 15 Apr 2010 14:46:45 -0400
To: XMLSec WG Public List <public-xmlsec@w3.org>
Message-Id: <1271357205.3096.44.camel@XMLSEC-BIZ.phub.net.cable.rogers.com>
Here are my comments regarding the 2010 March 4 draft of XML Signature

1) In the examples, the element with opening tag <dsig2:Selection>
closes with the mismatched closing tag <Selection>.

2) In section, in the phrase "addresses canonicalization for xml
data", the "xml" needs to be capitalized.

3) In section 3.2 Core Validation, we have added a step, since version
1.0, that the application checks that "each Reference ... matches the
expected data object". As essential as this is for many applications, it
seems to me that it is application-specific and I'm not completely sure
it should be considered part of core validation.

4) In 3.2.1 and elsewhere, replace the term "Dsig libraries" (or "Dsig
library") with something better (maybe "signature module").

5) In section, shouldn't "Explicit Curve Parameters" be
"Elliptic Curve Parameters"?

6) In section 4.5.8, "xenc:DerivedKey" needs matching angle brackets.

7) In section 4.6, it says "Note, if the application wishes to exclude
the <Object> tags from the digest calculation the Reference must
identify the actual data object (easy for XML documents)...". More
detail is needed here about how this is going to work in "2.0 mode"
given the new restrictions on the <Reference> @URI attribute and the
<dsig2:Selection> transform only returns element nodes (right?).

8) In section 6.7, descriptions of the @URI syntax need to be of the MAY
or MUST variety.

9) In section 6.7.1, shouldn't the description of the Selection Output
simply be "A set of one or more element nodes (such that no element is a
descendant of any other)."?

10) Throughout the document, capitalization of the <dsig2:Selection>
element's @Type attribute is inconsistent. Also the values of the @Type
attribute do not always seem to match their specification in section

11) Throughout the document, "xpath", when used in the text, needs to be

12) Throughout the document, change "surface representation" to "textual

13) In section 7, change "signed data can change between signing and
verification" to "signed data can change for legitimate reasons between
signing and verification".

14) Throughout the document, avoid using "parsing" where the term
"processing" will do.

Ed Simon, XMLsec Inc.
Received on Thursday, 15 April 2010 18:47:17 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:55:13 UTC