W3C home > Mailing lists > Public > w3c-ietf-xmldsig@w3.org > January to March 2007

XML DSig spec. errors (editorial) (a few more)

From: Daniel Barclay <daniel@fgm.com>
Date: Thu, 15 Feb 2007 15:30:10 -0500
Message-ID: <45D4C2D2.80407@fgm.com>
To: w3c-ietf-xmldsig@w3.org

The current XML-Signature Syntax and Processing specification at
http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/ contains
several editorial errors:

* Section 2.1 says "user specified algorithms" (which should be
   "user-specified algorithms").  Similarly, section 2.1.1 says
   "user specified transforms" (which should be "user-specified
   transforms").

* Section 2.1.1 says:

     The signing of the DigestValue is what binds a resources content
     to the signer's key.

   That should be:

     The signing of the DigestValue is what binds a resource's content
     to the signer's key.


* Section 2.2 says:

     Applications that wish to represent other semantics must rely upon
     other technologies, such as [XML, RDF].

   It seems that that should say:

     Applications that wish to represent other semantics must rely upon
     other technologies, such as XML [XML] or RDF [RDF].

   (The notation "[ID]" is like a supescripted footnote reference; to
   read right, the sentence needs to complete even if all such
   references are removed.)



* Section 8.1 says:

     For instance, applications that wish to sign a form, but permit
     users to enter limited field data without invalidating a previous
     signature on the form might use [XPath] to exclude those portions
     the user needs to change.

   The second comma seems imbalanced.  There probably should be a
   corresponding comma after "on the form."


* Section 8.1 also says:

     Note, core validation behavior does not confirm that the signed
     data was obtained by applying each step of the indicated
     transforms.

   That should probably start out as "Note:  Core ..." or "Note that
   core ..."

* Section 8.1 continues:

     (Though it does check that the digest of the resulting content
     matches that specified in the signature.)

   That sentence fragment should probably be combined with the previous
   sentence, e.g.:

     Note[: C]ore validation behavior does not confirm that the signed
     data was obtained by applying each step of the indicated
     transforms (though it does check that the digest of the resulting
     content matches that specified in the signature).

* Section 8.1.1 says:

     For instance, when an encrypted envelope contains a signature,
     the signature does not protect the authenticity or integrity of
     unsigned envelope headers nor its ciphertext form, it only secures
     the plaintext actually signed.

   The last comma should be a semicolon (or there should be a sentence
   break there).

* Section 8.3.1 says:

     To meet this recommendation where a document references an external
     style sheet, the content of that external resource should also be
     signed as via a signature Reference  otherwise the content of that
     external content might change which alters the resulting document
     without invalidating the signature.

   There should be a semicolon (or sentence break) before the word
   "otherwise."

* Section 8.1.3 says:

     All documents operated upon and generated by signature applications
     MUST be in [NFC, NFC-Corrigendum] ...

   That wording says that documents must be in the Normalization Form
   C specification instead of saying that the documents must be in
   Normalization Form C.

   It should probably say:

     All documents operated upon and generated by signature applications
     MUST be in NFC [NFC, NFC-Corrigendum] ...

* Section 8.2 says "user specified algorithms" (which should be
   "user-specified algorithms").  Later, it also says "user provided ...
   algorithms" (which should be "user-provided ... algorithms").

* Similarly, section 8.3 says "application defined algorithms" (which
   should be "application-defined algorithms").


Daniel



















-- 
Received on Thursday, 15 February 2007 20:30:26 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 15 February 2007 20:30:26 GMT