7. XML Canonicalization and Syntax Constraint Considerations ... 49
1. XML 1.0, Syntax Constraints, and Canonicalization ..... 50
2. DOM/SAX Processing and Canonicalization ................ 51
8. SecurityConsiderations ..................................... 52
1. Transforms ............................................. 52
1. Only What is Signed is Secure ..................... 52
2. Only What is "Seen" Should be Signed .............. 53
3. "See" What is Signed .............................. 53
2. Check the Security Model ............................... 54
3. Algorithms, Key Lengths, Etc. .......................... 54
9. Schema, DTD, Data Model,and Valid Examples .................. 55
10. Definitions ................................................. 56
11. References .................................................. 58
12. Authors' Addresses .......................................... 63
13. Full CopyrightStatement .................................... 64
For readability, brevity, and historic reasons this document uses
term "signature" to generally refer to digital authentication
of all types.Obviously, the term is also strictly used to refer
authentication values that are based on public keys and that
signer authentication. When specifically discussing
values based on symmetric secret key codes we use the
authenticators or authentication codes. (See Check the
Model, section 8.3.)
This specification uses both XML Schemas [XML-schema] and DTDs [XML].
(Readers unfamiliar with DTD syntax may wish to refer to
Bourret's "Declaring Elements and Attributes in an XML DTD
[Bourret].) The schema definition is presently normative
"they MUST only be used where it is actually required interoperation or to limit behavior which has potential
causing harm (e.g., limiting retransmissions)"
No provision is made for an explicit version number in this syntax
If a future version is needed, it will use a differentnamespace
XML namespace [XML-ns] URI that MUST be used by implementations
this (dated) specification is
xmlns="http://www.w3.org/2000/09/xmldsig#"
* John Cowan, Reuters
* Donald Eastlake 3rd, Motorola (Chair, Author/Editor
* Barb Fox, Microsoft (Author
* Christian Geuer-Pollmann, University
* Tom Gindin,
* Phillip Hallam-Baker, VeriSign
* Richard Himes, US
* Merlin Hughes,
* Gregor Karlinger, IAIK TU
* Brian LaMacchia,
* Peter Lipp, IAIK TU
* Joseph Reagle, W3C (Chair, Author/Editor
* Ed Simon, Entrust Technologies Inc. (Author
* David Solo, Citigroup (Author/Editor
* Petteri Stenius, DONE Information,
* Raghavan Srinivas,
* Kent Tamura,
* Winchel Todd Vincent III,
* Carl Wallace, Corsec Security, Inc
* Greg Whitehead, Signio Inc
* Dan Connolly, W3
* Paul Biron, Kaiser Permanente, on behalf of the XML Schema WG
* Martin J. Duerst, W3C; and Masahiro Sekiguchi, Fujitsu;
behalf of the Internationalization WG/IG
* Jonathan Marsh, Microsoft, on behalf of the
Stylesheet Language WG
XML Signatures are applied to arbitrary digital content (
objects) via an indirection. Data objects are digested,
resulting value is placed in an element (with other information)
that element is then digested and cryptographically signed.
digital signatures are represented by the Signature element which
Signatures are related to data objects via URIs [URI]. Within an document, signatures are related to local data objects via
identifiers. Such local data can be included within an signature or can enclose an enveloped signature. Detached
are over external network resources or local data objects
resides within the same XML document as sibling elements; in
case, the signature is neither enveloping (signature is parent)
enveloped (signature is child). Since a Signature element (and
Id attribute value/name) may co-exist or be combined with elements (and their IDs) within a single XML document, care should
taken in choosing names such that there are no subsequent
that violate the ID uniquenessvalidity constraint [XML].
[s02-12] The required SignedInfo element is the information that
actually signed. Core validation of SignedInfo consists of mandatory processes: validation of the signature over SignedInfo validation of each Reference digest within SignedInfo. Note that
algorithms used in calculating the SignatureValue are also
in the signed information while the SignatureValue element is
SignedInfo
[s03] The CanonicalizationMethod is the algorithm that is used
canonicalize the SignedInfo element before it is digested as part
the signatureoperation
[s05-11] Each Reference element includes the digest method
resulting digest value calculated over the identified data object
It also may include transformations that produced the input to
digest operation. A data object is signed by computing its
value and a signature over that value. The signature is
checked via reference and signaturevalidation
[s05-08] This identification, along with the transforms, is descriptionprovided by the signer on how they obtained the
data object in the form it was digested (i.e., the digested content).
The verifier may obtain the digested content in another method
long as the digest verifies. In particular, the verifier may
the content from a differentlocation such as a local store than specified in the URI
[s06-08] Transforms is an optional ordered list of processing
that were applied to the resource's content before it was digested
Transforms can include operations such as canonicalization encoding/decoding (including compression/inflation), XSLT and XPath
XPath transforms permit the signer to derive an XML document
omits portions of the source document. Consequently those
portions can change without affecting signaturevalidity.
example, if the resource being signed encloses the signature itself
such a transform must be used to exclude the signature value from
own computation. If no Transforms element is present, the resource'
content is digested directly. While we specify mandatory (
optional) canonicalization and decoding algorithms, user
transforms are permitted
[s09-10] DigestMethod is the algorithm applied to the data
Transforms is applied (if specified) to yield the DigestValue.
signing of the DigestValue is what binds a resources content to
signer's key
2.2 Extended Example (Object and SignatureProperty
[p04] The optional Type attribute of Referenceprovides
about the resource identified by the URI. In particular, it indicate that it is an Object, SignatureProperty, or
element. This can be used by applications to initiate processing of some Referenceelements. References to an XML
element within an Object element SHOULD identify the actual
pointed to. Where the element content is not XML (perhaps it
binary or encoded data) the reference should identify the Object
the Reference Type, if given, SHOULD indicate Object. Note that
is advisory and no action based on it or checking of its
is required by core behavior
[p10] Object is an optional element for including data objects
the signature element or elsewhere. The Object can be
typed and/or encoded
[p11-18] Signature properties, such as time of signing, can
optionally signed by identifying them from within a Reference
(These properties are traditionally called signature "attributes
although that term has no relationship to the XML term "attribute".)
1. Create SignedInfo element with SignatureMethod
CanonicalizationMethod and Reference(s).
2. Canonicalize and then calculate the SignatureValue over
based on algorithms specified in SignedInfo
3. Construct the Signature element that includes SignedInfo
Object(s) (if desired, encoding may be different than that
for signing), KeyInfo (if required), and SignatureValue
Note, there may be valid signatures that some signature
are unable to validate. Reasons for this include failure implementoptional parts of this specification, inability
unwillingness to execute specified algorithms, or inability
unwillingness to dereference specified URIs (some URI schemes
cause undesirable side effects), etc
1. Canonicalize the SignedInfo element based on
CanonicalizationMethod in SignedInfo
2. Obtain the data object to be digested. (The signature
may rely upon the identification (URI) and Transforms provided
the signer in the Reference element, or it may obtain the
through other means such as a local cache.)
3. Digest the resulting data object using the DigestMethod
in its Referencespecification
4. Compare the generated digest value against DigestValue in
SignedInfo Reference; if there is any mismatch, validation fails
Note, SignedInfo is canonicalized in step 1 to ensure the
Sees What is Signed, which is the canonical form. For instance,
the CanonicalizationMethod rewrote the URIs (e.g., relative URIs) the signatureprocessing must be cognizant of this
1. Obtain the keying information from KeyInfo or from an
source
2. Obtain the canonical form of the SignatureMethod using
CanonicalizationMethod and use the result (and previously
KeyInfo) to validate the SignatureValue over the
element
Additionally, the SignatureMethod URI may have been altered by
canonicalization of SignedInfo (e.g., absolutization of
URIs) and it is the canonical form that MUST be used. However, required canonicalization [XML-C14N] of this specification does
change URIs
Alternatives to the REQUIREDCanonical XML algorithm (section 6.5.2),
such as Canonical XML with Comments (section 6.5.2) and
Canonicalization (the CRLF and charset normalization specified
section 6.5.1), may be explicitly specified but are NOT REQUIRED
Consequently, their use may not interoperate with other
that do no support the specifiedalgorithm (see XML
and Syntax Constraint Considerations, section 7). Security
may also arise in the treatment of entity processing and comments
minimal or other non-XML aware canonicalization algorithms are
properly constrained (see section 8.2: Only What is "Seen" Should
Signed).
The way in which the SignedInfo element is presented to
canonicalization method is dependent on that method. The
applies to the two types of algorithms specified by this document
* Minimal canonicalization implementations MUST be provided
the octets that represent the well-formed SignedInfo element
from the first character to the last character of the representation, inclusive. This includes the entire text
Reference is an element that may occur one or more times. specifies a digest algorithm and digest value, and optionally identifier of the object being signed, the type of the object, and/
a list of transforms to be applied prior to digesting. identification (URI) and transforms describe how the digested
(i.e., the input to the digest method) was created. The attribute facilitates the processing of referenced data.
example, while this specification makes no requirements over
data, an application may wish to signal that the referent is
Manifest. An optional ID attribute permits a Reference to
referenced from elsewhere
Schema Definition
Reference (Transforms?, DigestMethod, DigestValue) >
Id ID #
URI CDATA #
Type CDATA #IMPLIED >
4.3.3.1 The URI
The URI attribute identifies a data object using a URI-Reference, specified by RFC2396 [URI]. The set of allowed characters for
attributes is the same as for XML, namely [Unicode]. However,
Unicode characters are disallowed from URI references including
non-ASCII characters and the excluded characters listed in RFC2396
[URI, section 2.4]. However, the number sign (#), percent sign (%),
and square bracket characters re-allowed in RFC 2732 [URI-Literal
are permitted. Disallowed characters must be escaped as follows
XML signatureapplications MUST be able to parse URI syntax. RECOMMEND they be able to dereference URIs in the HTTP scheme
Dereferencing a URI in the HTTP scheme MUST comply with the
Code Definitions of [HTTP] (e.g., 302, 305 and 307 redirects followed to obtain the entity-body of a 200 status code response). Applications should also be cognizant of the fact that parameter and state information, (such as a HTTP cookies, HTML profiles or content negotiation), may affect the content yielded
dereferencing a URI
If a resource is identified by more than one URI, the most
should be used (e.g. http://www.w3.org/2000/06/interop
pressrelease.html.en instead of http://www.w3.org/2000/06/interop
pressrelease). (See the ReferenceValidation (section 3.2.1) for
further information on referenceprocessing.)
* If the data object is a an octet stream and the
transformrequires a node-set, the signatureapplication
attempt to parse the octets
* If the data object is a node-set and the next
octets, the signatureapplication MUST attempt to convert
node-set to an octet stream using the REQUIRED algorithm [XML-C14N].
Users may specify alternative transforms that over-ride
defaults in transitions between Transforms that expect
inputs. The final octet stream contains the data octets
secured. The digest algorithmspecified by DigestMethod is
applied to these data octets, resulting in the DigestValue
Unless the URI-Reference is a 'same-document' reference as defined
[URI, Section 4.2], the result of dereferencing the URI-
MUST be an octet stream. In particular, an XML document
by URI is not parsed by the signatureapplication unless the URI is
same-documentreference or unless a transformthat requires
parsing is applied (See Transforms (section 4.3.3.1).)
URI="http://example.com/bar.xml
Identifies the octets that represent the external
'http//example.com/bar.xml', that is probably XML
given its file extension
URI="http://example.com/bar.xml#chapter1"
Identifies the element with ID attribute value 'chapter1'
the external XML resource 'http://example.com/bar.xml', provided as an octet stream. Again, for the sake interoperability, the element identified as 'chapter1'
be obtained using an XPath transformrather than a URI
(barename XPointer resolution in external resources is REQUIRED in this specification).
URI=""
Identifies the nodeset (minus any comment nodes) of the resourcecontaining the
URI="#chapter1"
Identifies a nodeset containing the element with ID
value 'chapter1' of the XML resourcecontaining the signature
XML Signature (and its applications) modify this nodeset
include the element plus all descendents including
and attributes -- but not comments
Dereferencing a same-documentreference MUST result in an
node-set suitable for use by Canonical XML. Specifically
dereferencing a null URI (URI="") MUST result in an XPath node-
that includes every non-comment node of the XML document
the URI attribute. In a fragment URI, the characters after
number sign ('#') character conform to the XPointer syntax [Xptr].
When processing an XPointer, the application MUST behave as if
root node of the XML documentcontaining the URI attribute were
to initialize the XPointer evaluation context. The application
behave as if the result of XPointer processing were a node-
derived from the resultant location-set as follows
1. discard point
2. replace each range node with all XPath nodes having full
partial content within the
3. replace the root node with its children (if it is in the node-set
4. replace any element node E with E plus all descendants of E (text
comment, PI, element) and all namespace and attribute nodes of
and its descendant elements
5. if the URI is not a full XPointer, then delete all comment
The second to last replacement is necessary because typicallyindicates a subtree of an XML document's parse tree
just the element node at the root of the subtree, whereas
XML treats a node-set as a set of nodes in which absence
descendant nodes results in absence of their representative text
the canonical form
The last step is performed for null URIs, barename XPointers
child sequence XPointers. To retain comments while selecting
element by an identifier ID, use the following full XPointer
URI='#xpointer(id("ID"))'. To retain comments while selecting
entire document, use the following full XPointer: URI='#xpointer(/)'.
This XPointer contains a simple XPath expression that includes
root node, which the second to last step above replaces with
nodes of the parse tree (all descendants, plus all attributes,
all namespaces nodes).
The optional Transforms element contains an ordered list of elements; these describe how the signer obtained the data object
was digested. The output of each Transform serves as input to
next Transform. The input to the first Transform is the result
dereferencing the URI attribute of the Reference element. The
from the last Transform is the input for the DigestMethod algorithm
When transforms are applied the signer is not signing the
(original) document but the resulting (transformed) document. (
Only What is Signed is Secure (section 8.1).)
As described in The ReferenceProcessing Model (section 4.3.3.2),
some transforms take an XPath node-set as input, while others
an octet stream. If the actual input matches the input needs of transform, then the transform operates on the unaltered input.
the transform input requirement differs from the format of the
input, then the input must be converted
