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:
- 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."
- 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"/>