Skip to main content

Exclusive XML Canonicalization, Version 1.0

The information below is for an old version of the document that is already published as an RFC.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 3741.
Authors Joseph Reagle, Donald E. Eastlake 3rd , John Boyer
Last updated 2020-01-21 (Latest revision 2003-12-03)
RFC stream Internet Engineering Task Force (IETF)
Additional resources Mailing list discussion
Stream WG state (None)
Document shepherd (None)
IESG IESG state RFC 3741 (Informational)
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD Russ Housley
IESG note The revised draft includes the changes requested by Randy Bush. It is back on the agenda to confirm that there are no further concerns.
Send notices to (None)
INTERNET-DRAFT                                                John Boyer
                                                      PureEdge Solutions
                                                  Donald E. Eastlake 3rd
                                                           Joseph Reagle
Expires: June 2004                                         December 2003

              Exclusive XML Canonicalization, Version 1.0
              --------- --- ----------------- ------- ---

Status of This Document

   Distribution of this draft is unlimited. Comments should be sent to
   the XMLDSIG working group mailing list or to the authors.

   This document is an Internet Draft and is in full conformance with
   all provisions of Section 10 of RFC 2026.  Internet Drafts are
   working documents of the Internet Engineering Task Force (IETF), its
   areas, and its working groups.  Note that other groups may also
   distribute working documents as Internet Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at

   The list of Internet-Draft Shadow Directories can be accessed at

Copyright Notice

   Copyright (C) 2003 The Internet Society & W3C (MIT, INRIA, Keio), All
   Rights Reserved.

J. Boyer, D. Eastlake 3rd, J. Reagle                            [Page 1]

INTERNET-DRAFT       Exclusive XML Canonicalization        December 2003


   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 ancestor
   context from a canonicalized subdocument. For example, one might
   require a digital signature over an XML payload (subdocument) in an
   XML message that will not break when that subdocument is removed from
   its original message and/or inserted into a different context.  This
   requirement is satisfied by Exclusive XML Canonicalization.

W3C Status of this document

   W3C Recommendation 18 July 2002

   This version:
   Latest version:

   This document is the W3C (World Wide Web Consortium) Exclusive
   Canonicalization Recommendation. This document has been reviewed by
   W3C Members and other interested parties and has been endorsed by the
   Director as a W3C Recommendation. It is a stable document and may be
   used as reference material or cited as a normative reference from
   another document. W3C's role in making the Recommendation is to draw
   attention to the specification and to promote its widespread
   deployment. This enhances the functionality and interoperability of
   the Web.

J. Boyer, D. Eastlake 3rd, J. Reagle                            [Page 2]

INTERNET-DRAFT       Exclusive XML Canonicalization        December 2003

Table of Contents

      Status of This Document....................................1
      Copyright Notice...........................................1

      W3C Status of this document................................2

      Table of Contents..........................................3

      1. Introduction............................................4
      1.1 Terminology............................................4
      1.2 Applications...........................................6
      1.3 Limitations............................................6
      2. The Need for Exclusive XML Canonicalization.............7
      2.1 A Simple Example.......................................7
      2.2 General Problems with re-Enveloping....................8
      3. Specification of Exclusive XML Canonicalization........10
      3.1 Constrained Implementation (non-normative)............11
      4. Use in XML Security....................................12
      5. Security Considerations................................13
      5.1 Target Context........................................13
      5.2 'Esoteric' Node-sets..................................14
      6. References.............................................14
      7. Acknowledgements (Informative).........................15

      Authors Addresses.........................................16

      Full Copyright Statement..................................17
      Expiration and File Name..................................17

J. Boyer, D. Eastlake 3rd, J. Reagle                            [Page 3]

INTERNET-DRAFT       Exclusive XML Canonicalization        December 2003

1. Introduction

   The XML Recommendation [XML] specifies the syntax of a class of
   objects called XML documents. The Namespaces in XML Recommendation
   [XML-NS] specifies additional syntax and semantics for XML documents.
   It is normal for XML documents and subdocuments which are equivalent
   for the purposes of many applications to differ in their physical
   representation. For example, they may differ in their entity
   structure, attribute ordering, and character encoding. The goal of
   this specification is to establish a method for serializing the XPath
   node-set representation of an XML document or subset such that:

     1. The node-set is minimally affected by any XML context which has
        been omitted.
     2. The canonicalization of a node-set representing well-balanced
        XML [XML-Fragment] will be unaltered by further applications of
        exclusive canonicalization.
     3. It can be determined whether two node-sets are identical except
        for transformations considered insignificant by this
        specification under [XML, XML-NS].

   An understanding of the Canonical XML Recommendation [XML-C14N] is

1.1 Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in RFC 2119 [Keywords].

   The XPath 1.0 Recommendation [XPath] defines the term node-set and
   specifies a data model for representing an input XML document as a
   set of nodes of various types (element, attribute, namespace, text,
   comment, processing instruction, and root). The nodes are included in
   or excluded from a node-set based on the evaluation of an expression.
   Within this specification and [XML-C14N], a node-set is used to
   directly indicate whether or not each node should be rendered in the
   canonical form (in this sense, it is used as a formal mathematical
   set). A node that is excluded from the set is not rendered in the
   canonical form being generated, even if its parent node is included
   in the node-set. However, an omitted node may still impact the
   rendering of its descendants (e.g. by affecting the namespace context
   of the descendants).

   A document subset is a portion of an XML document indicated by an
   XPath node-set that may not include all of the nodes in the document.
   As defined in [XPath] every node (e.g., element, attribute, and
   namespace), has exactly one parent, which is either an element node

J. Boyer, D. Eastlake 3rd, J. Reagle                            [Page 4]

INTERNET-DRAFT       Exclusive XML Canonicalization        December 2003

   or the root node. An apex node is an element node in a document
   subset having no element node ancestor in the document subset. An
   orphan node is an element node whose parent element node is not in
   the document subset. The output parent of an orphan node that is not
   an apex node is the nearest ancestor element of the orphan node that
   is in the document subset; an apex node has no output parent. The
   output parent of a non-orphan node is the parent of the node. An
   output ancestor is any ancestor element node in the document subset.

   For example given a document tree with three generations under the
   root node A and where capitalization denotes the node is in the
   document subset (A,E,G).

   Pictorial Representation:

     [diagram of nodes,]

   Textual Representation:

   The following characteristics apply:

      * A is an apex node, output parent of E, and output ancestor of
      * E is an orphan node and the output parent of G.

   An element E in a document subset visibly utilizes a namespace
   declaration, i.e. a namespace prefix P and bound value V, if E or an
   attribute node in the document subset with parent E has a qualified
   name in which P is the namespace prefix. A similar definition applies
   for an element E in a document subset that visibly utilizes the
   default namespace declaration, which occurs if E has no namespace

   The namespace axis of an element contains nodes for all non-default
   namespace declarations made within the element as well as non-default
   namespace declarations inherited from ancestors of the element. The
   namespace axis also contains a node representing the default
   namespace if it is not the empty string, whether the default
   namespace was declared within the element or by an ancestor of the
   element. Any subset of the nodes in a namespace axis can be included
   in a document subset.

   The method of canonicalization described in this specification
   receives an InclusiveNamespaces PrefixList parameter, which lists
   namespace prefixes that are handled in the manner described by the

J. Boyer, D. Eastlake 3rd, J. Reagle                            [Page 5]

INTERNET-DRAFT       Exclusive XML Canonicalization        December 2003

   Canonical XML Recommendation [XML-C14N].

   The exclusive canonical form of a document subset is a physical
   representation of the XPath node-set, as an octet sequence, produced
   by the method described in this specification. It is as defined in
   the Canonical XML Recommendation [XML-C14N] except for the changes
   summarized as follows:

      * attributes in the XML namespace, such as xml:lang and xml:space
      are not imported into orphan nodes of the document subset, and
      * namespace nodes that are not on the InclusiveNamespaces
      PrefixList are expressed only in start tags where they are visible
      and if they are not in effect from an output ancestor of that tag.

   The term exclusive canonical XML refers to XML that is in exclusive
   canonical form. The exclusive XML canonicalization method is the
   algorithm defined by this specification that generates the exclusive
   canonical form of a given XML document subset. The term exclusive XML
   canonicalization refers to the process of applying the exclusive XML
   canonicalization method to an XML document subset.

1.2 Applications

   The applications of Exclusive XML Canonicalization are very similar
   to those for Canonical XML [XML-C14N]. However, exclusive
   canonicalization, or equivalent means of excluding most XML context,
   is necessary for signature applications where the XML context of
   signed XML will change. This sort of change is typical of many
   protocol applications.

   Note that in the case of the SignedInfo element of [XML-DSig], the
   specification of an appropriate canonicalization method is the only
   technique available to protect the signature from insignificant
   changes in physical form and changes in XML context.

1.3 Limitations

   Exclusive XML Canonicalization has the limitations of Canonical XML
   [XML-C14N] plus two additional limitations as follows:

     1. The XML being canonicalized may depend on the effect of XML
        namespace attributes, such as xml:lang, xml:space, and xml:base
        appearing in ancestor nodes. To avoid problems due to the non-
        importation of such attributes into an enveloped document
        subset, either they MUST be explicitly given in a node of the
        XML document subset being canonicalized where their effect is

J. Boyer, D. Eastlake 3rd, J. Reagle                            [Page 6]

INTERNET-DRAFT       Exclusive XML Canonicalization        December 2003

        needed or which is an ancestor of the node where their effect is
        needed or they MUST always be declared with an equivalent value
        in every context in which the XML document subset will be
     2. Applications that use the XML being canonicalized may depend on
        the effect of XML namespace declarations where the namespace
        prefix being bound is not visibly utilized. An example would be
        an attribute whose value is an XPath expression and whose
        evaluation therefore depends upon namespace prefixes referenced
        in the expression. Or, an attribute value might be considered a
        QName [XML-NS] by some applications, but it is only a string-
        value to XPath:

        <number xsi:type="xsd:decimal">10.09</number>.

        To avoid problems with such namespace declarations,

          o the XML MUST be modified so that use of the namespace prefix
             involved is visible, or
          o the namespace declarations MUST appear and be bound to the
             same values in every context in which the XML will be
             interpreted, or
          o the prefixes for such namespaces MUST appear in the
             InclusiveNamespaces PrefixList.

2. The Need for Exclusive XML Canonicalization

   In some cases, particularly for signed XML in protocol applications,
   there is a need to canonicalize a subdocument in such a way that it
   is substantially independent of its XML context. This is because, in
   protocol applications, it is common to envelope XML in various layers
   of message or transport elements, to strip off such enveloping, and
   to construct new protocol messages, parts of which were extracted
   from different messages previously received. If the pieces of XML in
   question are signed, they need to be canonicalized in a way such that
   these operations do not break the signature but the signature still
   provides as much security as can be practically obtained.

2.1 A Simple Example

   As a simple example of the type of problem that changes in XML
   context can cause for signatures, consider the following document:

      <n1:elem1 xmlns:n1="http://b.example">

J. Boyer, D. Eastlake 3rd, J. Reagle                            [Page 7]

INTERNET-DRAFT       Exclusive XML Canonicalization        December 2003

   this is then enveloped in another document:

      <n0:pdu xmlns:n0="http://a.example">
         <n1:elem1 xmlns:n1="http://b.example">

   The first document above is in canonical form. But assume that
   document is enveloped as in the second case. The subdocument with
   elem1 as its apex node can be extracted from this second case with an
   XPath expression such as:

    (//. | //@* | //namespace::*)[ancestor-or-self::n1:elem1]

   The result of applying Canonical XML to the resulting XPath node-set
   is the following (except for line wrapping to fit this document):

      <n1:elem1 xmlns:n0="http://a.example"

   Note that the n0 namespace has been included by Canonical XML because
   it includes namespace context. This change which would break a
   signature over elem1 based on the first version.

2.2 General Problems with re-Enveloping

   As a more complete example of the changes in canonical form that can
   occur when the enveloping context of a document subset is changed,
   consider the following document:

      <n0:local xmlns:n0="foo:bar"
         <n1:elem2 xmlns:n1=""
             <n3:stuff xmlns:n3=""/>

   And the following which has been produced by changing the enveloping
   of elem2:

      <n2:pdu xmlns:n1=""

J. Boyer, D. Eastlake 3rd, J. Reagle                            [Page 8]

INTERNET-DRAFT       Exclusive XML Canonicalization        December 2003

         <n1:elem2 xmlns:n1=""
             <n3:stuff xmlns:n3=""/>

   Assume an XPath node-set produced from each case by applying the
   following XPath expression:

    (//. | //@* | //namespace::*)[ancestor-or-self::n1:elem2]

   Applying Canonical XML to the node-set produced from the first
   document yields the following serialization (except for line wrapping
   to fit in this document):

      <n1:elem2 xmlns:n0="foo:bar"

   However, although elem2 is represented by the same octet sequence in
   both pieces of external XML above, the Canonical XML version of elem2
   from the second case would be (except for line wrapping so it will
   fit into this document) as follows:

      <n1:elem2 xmlns:n1=""
          <n3:stuff xmlns:n3=""></n3:stuff>

   Note that the change in context has resulted in lots of changes in
   the subdocument as serialized by the inclusive Canonical XML [XML-
   C14N]. In the first example, n0 had been included from the context
   and the presence of an identical n3 namespace declaration in the
   context had elevated that declaration to the apex of the
   canonicalized form. In the second example, n0 has gone away but n2
   has appeared, n3 is no longer elevated, and an xml:space declaration
   has appeared, due to changes in context. But not all context changes
   have effect. In the second example, the presence at ancestor nodes of
   an xml:lang and n1 prefix namespace declaration have no effect
   because of existing declarations at the elem2 node.

   On the other hand, using Exclusive XML Canonicalization as specified
   herein, the physical form of elem2 as extracted by the XPath
   expression above is (except for line wrapping so it will fit into
   this document) as follows:

J. Boyer, D. Eastlake 3rd, J. Reagle                            [Page 9]

INTERNET-DRAFT       Exclusive XML Canonicalization        December 2003

      <n1:elem2 xmlns:n1=""
          <n3:stuff xmlns:n3=""></n3:stuff>

   in both cases.

3. Specification of Exclusive XML Canonicalization

   The data model, processing, input parameters, and output data for
   Exclusive XML Canonicalization are the same as for Canonical XML
   [XML-C14N] with the following exceptions:

     1. Canonical XML applied to a document subset requires the search
        of the ancestor nodes of each orphan element node for attributes
        in the XML namespace, such as xml:lang and xml:space. These are
        copied into the element node except if a declaration of the same
        attribute is already in the attribute axis of the element
        (whether or not it is included in the document subset). This
        search and copying are omitted from the Exclusive XML
        Canonicalization method.
     2. The Exclusive XML Canonicalization method may receive an
        additional, possibly null, parameter InclusiveNamespaces
        PrefixList containing a list of namespace prefixes and/or a
        token indicating the presence of the default namespace. All
        namespace nodes appearing on this list are handled as provided
        in Canonical XML [XML-C14N].
     3. A namespace node N with a prefix that does not appear in the
        InclusiveNamespaces PrefixList is rendered if all of the
        conditions are met:
          1. Its parent element is in the node-set, and
          2. it is visibly utilized by its parent element, and
          3. the prefix has not yet been rendered by any output
             ancestor, or the nearest output ancestor of its parent
             element that visibly utilizes the namespace prefix does not
             have a namespace node in the node-set with the same
             namespace prefix and value as N.
     4. If the token representing the default namespace is not present
        in InclusiveNamespaces PrefixList, then the rules for rendering
        xmlns="" are changed as follows. When canonicalizing the
        namespace axis of an element E that is in the node-set, output
        xmlns="" if and only if all of the conditions are met:
          1. E visibly utilizes the default namespace (i.e., it has no
             namespace prefix), and
          2. it has no default namespace node in the node-set, and
          3. the nearest output ancestor of E that visibly utilizes the
             default namespace has a default namespace node in the node-

J. Boyer, D. Eastlake 3rd, J. Reagle                           [Page 10]

INTERNET-DRAFT       Exclusive XML Canonicalization        December 2003

        (This step for for xmlns="" is necessary because it is not
        represented in the XPath data model as a namespace node, but as
        the absence of a namespace node; see  Section 4.7 Propagation of
        Default Namespace Declaration in Document Subsets [XML-C14N].)

3.1 Constrained Implementation (non-normative)

   The following is a (non-normative) method for implementing the
   Exclusive XML Canonicalization method for many straightforward cases
   -- it assumes a well-formed subset and that if an element is in the
   node-set, so is all of its namespace axis; if the element is not in
   the subset, neither is its namespace axis.

     1. Recursively process the entire tree (from which the XPath node-
        set was selected) in document order starting with the root. (The
        operation of copying ancestor xml: namespace attributes into
        output apex element nodes is not done.)
     2. If the node is not in the XPath subset, continue to process its
        children element nodes recursively.
     3. If the element node is in the XPath subset then output the node
        in accordance with Canonical XML except for namespace nodes
        which are rendered as follows:
          1. ns_rendered is a copy of a dictionary, off the top of the
             state stack, of prefixes and their values which have
             already been rendered by an output ancestor of the
             namespace node's parent element.
          2. Render each namespace node if and only if all of the
             conditions are met:
               1. it is visibly utilized by the immediate parent element
                  or one of its attributes, or is present in
                  InclusiveNamespaces PrefixList, and
               2. its prefix and value do not appear in ns_rendered.
          3. Render xmlns="" if and only if all of the conditions are
               1. The default namespace is visibly utilized by the
                  immediate parent element node, or the default prefix
                  token is present in InclusiveNamespaces PrefixList,
               2. the element does not have a namespace node in the
                  node-set declaring a value for the default namespace,
               3. the default namespace prefix is present in the
                  dictionary ns_rendered.
          4. Insert all the rendered namespace nodes (including
             xmlns="") into the ns_rendered dictionary, replacing any
             existing entries. Push ns_rendered onto the state stack and
          5. After the recursion returns, pop the state stack.

J. Boyer, D. Eastlake 3rd, J. Reagle                           [Page 11]

INTERNET-DRAFT       Exclusive XML Canonicalization        December 2003

4. Use in XML Security

   Exclusive Canonicalization may be used as a Transform or
   CanonicalizationMethod algorithm in XML Digital Signature [XML-DSig]
   and XML Encryption [XML-Enc].


   Just as with [XML-C14N] one may use the "#WithComments" parameter to
   include the serialization of XML comments. This algorithm also takes
   an optional explicit parameter of an empty InclusiveNamespaces
   element with a PrefixList attribute. The value of this attribute is a
   white space delimited list of namespace prefixes, and where #default
   indicates the default namespace, to be handled as per [XML-C14N]. The
   list is in NMTOKENS format (a white space separated list). For

         <ec:InclusiveNamespaces PrefixList="dsig soap #default"

   indicates the exclusive canonicalization transform, but that
   namespaces with prefix "dsig" or "soap" and default namespaces should
   be processed according to [XML-C14N].

      Schema Definition:

      <?xml version="1.0" encoding="utf-8"?>
      <!DOCTYPE schema
        PUBLIC "-//W3C//DTD XMLSchema 200102//EN"
         <!ATTLIST schema xmlns:ec CDATA
                   #FIXED ''>
         <!ENTITY ec ''>
         <!ENTITY % p ''>
         <!ENTITY % s ''>

      <schema xmlns=""
              version="0.1" elementFormDefault="qualified">

        <element name="InclusiveNamespaces"

J. Boyer, D. Eastlake 3rd, J. Reagle                           [Page 12]

INTERNET-DRAFT       Exclusive XML Canonicalization        December 2003

        <complexType name="InclusiveNamespaces">
           <attribute name="PrefixList" type="NMTOKENS"/>

      <!ELEMENT InclusiveNamespaces    EMPTY >
      <!ATTLIST InclusiveNamespaces
         PrefixList    NMTOKENS    #REQUIRED >

5. Security Considerations

   This specification is used to serialize an XPath node-set under
   certain assumptions given in [XML-C14N] and this specification. Three
   such examples include:

     1. implementations of [XML-C14N] and this specification do not
        render an XML declaration;
     2. implementations of this specification only render attributes
        from the "XML" namespace (e.g., xml:lang, xml:space, and
        xml:base) when they are in the subset being serialized;
     3. implementations of this specification do not consider the
        appearance of a namespace prefix within an attribute value to be
        visibly utilized.

   While such choices are consistent with other XML specifications and
   satisfy the Working Group's application requirements it is important
   that an XML application carefully construct its transforms such that
   the result is meaningful and unambiguous in its application context.
   In addition to this section, the Limitations of this specification,
   the Resolutions of [XML-C14N], and the Security Considerations of
   [XML-DSig] should be carefully attended to.

5.1 Target Context

   The requirement of this specification is to satisfy applications that
   "require a method which, to the extent practical, excludes ancestor
   context from a canonicalized subdocument." Given a fragment being
   removed from its source instance, this specification satisfies this
   requirement by excluding from the fragment any context from its
   ancestors that is not utilized.  Consequently, a signature [XML-DSig]
   over that fragment will remain valid in its source context, removed
   from the source context, and even in a new target context. However,
   this specification does not insulate the fragment against confused
   interpretation in a target context.

J. Boyer, D. Eastlake 3rd, J. Reagle                           [Page 13]

INTERNET-DRAFT       Exclusive XML Canonicalization        December 2003

   For example, if the <Foo/> element is signed in its source instance
   of <Bar/><Foo/></Bar> and then removed and placed in the target
   instance <Baz xmlns=""/><Foo/></Baz>, the
   signature should still be valid, but won't be if <Foo/> is
   interprated as belonging to the namespace:
   this is dependent on how nodes are processed.

   This specification does not define mechanisms of removing, inserting,
   and "fixing up" a node-set. (For an example of this sort of
   specification, see the processing required of Creating the Result
   Infoset (section 4.5) when an [XInclude] is performed.) Instead,
   applications must carefully specify the XML (i.e., source, fragment,
   and target) or define the node-set processing (i.e., removal,
   replacement, and insertion) with respect to default namespace
   declarations (e.g., xmlns="") and XML attributes (e.g., xml:lang,
   xml:space, and xml:base).

5.2 'Esoteric' Node-sets

   Consider an application that might use this specification or [XML-
   C14N] to serialize a single attribute node. An implementation of
   either specification will not emit a namespace declaration for that
   single attribute node.  Consequently, a "carefully constructed"
   transform should create a node-set containing the attribute and the
   relevant namespace declaration for serialization.

   This example is provided to caution that as one moves beyond well-
   formed [XML] and then well-balanced XML [XML-Fragment], it becomes
   increasingly difficult to create a result that "is meaningful and
   unambiguous in its application context."

6. References

   [Keywords] - RFC 2119. Key words for use in RFCs to Indicate
   Requirement Levels. S.  Bradner. Best Current Practice, March 1997.
   Available at

   [URI] - RFC 2396 . Uniform Resource Identifiers (URI): Generic
   Syntax. T.  Berners-Lee, R. Fielding, and L. Masinter. Standards
   Track, August 1998.  Available at

   [XML] - Extensible Markup Language (XML) 1.0 (Second Edition). T.
   Bray, E.  Maler, J. Paoli, and C. M. Sperberg-McQueen. W3C
   Recommendation, October 2000.  Available at .

J. Boyer, D. Eastlake 3rd, J. Reagle                           [Page 14]

INTERNET-DRAFT       Exclusive XML Canonicalization        December 2003

   [XML-C14N] - RFC 3076. "Canonical XML", J. Boyer, March 2001. Also a
   W3C Recommendation available at

   [XML-DSig] - XML-Signature Syntax and Processing. D. Eastlake, J.
   Reagle, and D.  Solo. IETF Draft Standard/W3C Recommendation, August
   2001.  Available at

   [XML-Fragment] - XML Fragment Interchange. P. Grosso, and D.
   Veillard. W3C Candidate Recommendation, February 2001.  Available at

   [XInclude] - XML Inclusions (XInclude) Version 1.0. J. Marsh, and D.
   Orchad. W3C Candidate Recommendation, February 2002.  Available at

   [XML-NS] - Namespaces in XML. T. Bray, D. Hollander, and A. Layman.
   W3C Recommendation, January 1999.  Available at

   [XML-Enc] - XML Encryption Syntax and Processing. D. Eastlake, and J.
   Reagle. W3C Candidate Recommendation, March 2002.  Available at

   [XML-schema] - XML Schema Part 1: Structures D. Beech, M. Maloney, N.
   Mendelsohn, and H. Thompson. W3C Recommendation, May 2001.  Available

   [XPath] - XML Path Language (XPath) Version 1.0. J. Clark and S.
   DeRose. W3C Recommendation, November 1999.  Available at

7. Acknowledgements (Informative)

   The following people provided valuable feedback that improved the
   quality of this specification:

        * Merlin Hughes, Baltimore
        * Thomas Maslen, DSTC
        * Paul Denning, MITRE
        * Christian Geuer-Pollmann, University Siegen
        * Bob Atkinson, Microsoft

J. Boyer, D. Eastlake 3rd, J. Reagle                           [Page 15]

INTERNET-DRAFT       Exclusive XML Canonicalization        December 2003

Authors Addresses

   John Boyer
   PureEdge Solutions Inc.
   4396 West Saanich Rd.
   Victoria, BC, Canada V8Z 3E9

   Phone: 1-888-517-2675

   Donald E. Eastlake 3rd
   155 Beaver Street
   Milford, MA 01757 USA

   Telephone:   +1-508-634-2066 (h)
                +1-508-786-7554 (w)

   Joseph M. Reagle Jr., W3C
   Massachusetts Institute of Technology
   Laboratory for Computer Science
   NE43-350, 545 Technology Square
   Cambridge, MA 02139

   Phone: +1.617.258.7621

J. Boyer, D. Eastlake 3rd, J. Reagle                           [Page 16]

INTERNET-DRAFT       Exclusive XML Canonicalization        December 2003

Full Copyright Statement

   Copyright (C) 2003 The Internet Society & W3C (MIT, INRIA, Keio), All
   Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an

Expiration and File Name

   This draft expires June 2004.

   Its file name is draft-ietf-xmldsig-xc14n-02.txt.

J. Boyer, D. Eastlake 3rd, J. Reagle                           [Page 17]