Errata of the XML-Signature Syntax and Processing Specification

About the XML-Signature Syntax and Processing Specification

The XML-Signature Syntax and Processing Recommendation has been produced by the IETF/W3C XML Signature Working..

This document lists the known errata to the XML Signature specification. Each entry has the following information:

• A unique entry number.
• The date it was added to the errata page.
• Whether the entry is considered:
  • an Error that affects the conformance and/or interoperability of syntax and processing,
  • an Editorial error, such as a typographical mistake,
  • a structural defect in the Document, such as an incorrect fragment identifier,
  • a Clarification with respect to a misstatement or misinterpretation of the specification,
  • a Caveat where subsequent experience has shown that a recommendation of the specification was incorrect or needs further qualification.
• The version and section referred to.
• A description of the problem and correction if applicable.

Note: All errata listed on this page have been taken into account in the preparation of XML Signature, 2nd Edition. See the documentation of Changes in XML Signature Syntax and Processing (Second Edition) for details, and Errata for XML Signature 2nd Edition for Errata against the Second edition.

Please report errors in this document to the editor and cc: the public email list w3c-ietf-xmldsig@w3.org (archive).

XML-Signature Syntax and Processing

E01 2002-01-28 (Editorial):

The encoding of string values within a DNAME provided by the xmldsig specification is not strictly RFC2253 [LDAP-DN] compliant; there are differences with respect to their encoding in XML documents. Consequently:

1. Section 4.4.4 The X509Data Element: The first two bullets of list item "1" should read, "the encoding of the distinguished name SHOULD be compliant with the DNAME encoding rules at the end of this section."
2. The text at the end of the section should read, "DNames (X509IssuerSerial, X509SubjectName, and KeyName if appropriate) should be encoded in accordance with RFC2253 [LDAP-DN] except for the encoding of string values within a DName:"

E02 2002-01-29 (Caveat):

In Algorithms (Section 6) the Canonical XML Recommendation is referenced as a general purpose canonicalization algorithm. However, the Exclusive XML Canonicalization specification is now available to address requirements resulting from scenarios where a subdocument is moved between contexts. "Canonical XML [XML-C14N] specifies a standard serialization of XML that, when applied to a subdocument, includes the subdocument's ancestor context including all of the namespace declarations and attributes in the 'xml:' namespace. However, some applications require a method which, to the extent practical, excludes unused ancestor context from a canonicalized subdocument."

E03 2002-01-29 (Caveat):

XPath Filtering (Section 6.6.3) is specified as a mechanism of "omitting precisely those nodes that are allowed to change once the signature is affixed, and including all other input nodes in the output." There are reports that implementations are performing poorly -- perhaps because they rely upon suboptimal XPath implementations. Implementors have requested an XPath transform that permits the easy specification of subtree selection and omission that can be efficiently implemented. This is now available as the XML-Signature XPath Filter 2.0 Recommendation.

E04 2002-03-20 (Clarification)

6.5 Canonicalization Algorithms states for canonicalization with and without comments, "The two algorithms below perform text normalization during transcoding [NFC, NFC-Corrigendum]." While it is true the output of these algorithms will be in NFC it is not because they do the normalization themselves, but because "the XML processor used to prepare the XPath data model input is required (by the Data Model) to use Normalization Form C [NFC, NFC-Corrigendum] when converting an XML document to the UCS character domain from any encoding that is not UCS-based..." [XML-C14N, 4.2 No Character Model Normalization].

E05 2002-05-08 (Clarification)

The Type attribute described within 4.3.3.1 The URI Attribute and 4.4.3 The RetrievalMethod Element "contains information about the type of object being signed." The object being signed is the result of the Referencing Processing Model, including any specified transforms. It is incorrect to use the Type to describe the object that is identified via the Reference URI prior to its input to any transforms.

E06 2002-06-06 (Error)

The example of the informational Encoding attribute within 4.5 The Object Element is incorrectly given as a string 'base64' instead of as a URI. The statement should read, "For example, if the data that is encrypted is a base64 encoded PNG, the Encoding may be specified as 'http://www.w3.org/2000/09/xmldsig#base64' and the MimeType as 'image/png'."

E07 2003-01-10 (Editorial)

6.4.2 PKCS1 (RSA-SHA1) states, "as used in this draft", which should read, "as used in this specification"

E08 2003-11-18 (Error)

The schema declaration for ds:RetrievalMethod (in Section 4.4.3) is missing the required schema attribute. It should read: <attribute name="URI" type="anyURI" use="required"/>