rfc3076.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,572 行 · 第 1/5 页

Network Working Group                                           J. Boyer
Request for Comments: 3076                       PureEdge Solutions Inc.
Category: Informational                                       March 2001


                       Canonical XML Version 1.0

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2001).  All Rights Reserved.

Abstract

   Any XML (Extensible Markup Language) document is part of a set of XML
   documents that are logically equivalent within an application
   context, but which vary in physical representation based on syntactic
   changes permitted by XML 1.0 and Namespaces in XML.  This
   specification describes a method for generating a physical
   representation, the canonical form, of an XML document that accounts
   for the permissible changes.  Except for limitations regarding a few
   unusual cases, if two documents have the same canonical form, then
   the two documents are logically equivalent within the given
   application context.  Note that two documents may have differing
   canonical forms yet still be equivalent in a given context based on
   application-specific equivalence rules for which no generalized XML
   specification could account.



















Boyer                        Informational                      [Page 1]

RFC 3076                     Canonical XML                    March 2001


Table of Contents

   1. Introduction...............................................  2
   1.1 Terminology...............................................  3
   1.2 Applications..............................................  4
   1.3 Limitations...............................................  4
   2. XML Canonicalization.......................................  6
   2.1 Data Model................................................  6
   2.2 Document Order............................................ 10
   2.3 Processing Model.......................................... 10
   2.4 Document Subsets.......................................... 13
   3. Examples of XML Canonicalization........................... 14
   3.1 PIs, Comments, and Outside of Document Element............ 14
   3.2 Whitespace in Document Content............................ 15
   3.3 Start and End Tags........................................ 16
   3.4 Character Modifications and Character References.......... 17
   3.5 Entity References......................................... 19
   3.6 UTF-8 Encoding............................................ 19
   3.7 Document Subsets.......................................... 20
   4. Resolutions................................................ 21
   4.1 No XML Declaration........................................ 21
   4.2 No Character Model Normalization.......................... 21
   4.3 Handling of Whitespace Outside Document Element........... 22
   4.4 No Namespace Prefix Rewriting............................. 22
   4.5 Order of Namespace Declarations and Attributes............ 23
   4.6 Superfluous Namespace Declarations........................ 23
   4.7 Propagation of Default Namespace Declaration in Document
       Subsets................................................... 24
   4.8 Sorting Attributes by Namespace URI....................... 24
   Security Considerations....................................... 24
   References.................................................... 25
   Author's Address.............................................. 26
   Acknowledgements.............................................. 27
   Full Copyright Statement...................................... 28

1. Introduction

   The XML 1.0 Recommendation [XML] specifies the syntax of a class of
   resources called XML documents.  The Namespaces in XML Recommendation
   [Names] specifies additional syntax and semantics for XML documents.
   It is possible for XML documents which are equivalent for the
   purposes of many applications to differ in physical representation.
   For example, they may differ in their entity structure, attribute
   ordering, and character encoding.  It is the goal of this
   specification to establish a method for determining whether two
   documents are identical, or whether an application has not changed a
   document, except for transformations permitted by XML 1.0 and
   Namespaces.



Boyer                        Informational                      [Page 2]

RFC 3076                     Canonical XML                    March 2001


1.1 Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [Keywords].

   See [Names] for the definition of QName.

   A document subset is a portion of an XML document indicated by a
   node-set that may not include all of the nodes in the document.

   The canonical form of an XML document is physical representation of
   the document produced by the method described in this specification.
   The changes are summarized in the following list:

       * The document is encoded in UTF-8
       * Line breaks normalized to #xA on input, before parsing
       * Attribute values are normalized, as if by a validating
         processor
       * Character and parsed entity references are replaced
       * CDATA sections are replaced with their character content
       * The XML declaration and document type declaration (DTD) are
         removed
       * Empty elements are converted to start-end tag pairs
       * Whitespace outside of the document element and within start and
         end tags is normalized
       * All whitespace in character content is retained (excluding
         characters removed during line feed normalization)
       * Attribute value delimiters are set to quotation marks (double
         quotes)
       * Special characters in attribute values and character content
         are replaced by character references
       * Superfluous namespace declarations are removed from each
         element
       * Default attributes are added to each element
       * Lexicographic order is imposed on the namespace declarations
         and attributes of each element

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

   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,



Boyer                        Informational                      [Page 3]

RFC 3076                     Canonical XML                    March 2001


   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, 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 augmenting the namespace
   context of the descendants).

1.2 Applications

   Since the XML 1.0 Recommendation [XML] and the Namespaces in XML
   Recommendation [Names] define multiple syntactic methods for
   expressing the same information, XML applications tend to take
   liberties with changes that have no impact on the information content
   of the document.  XML canonicalization is designed to be useful to
   applications that require the ability to test whether the information
   content of a document or document subset has been changed.  This is
   done by comparing the canonical form of the original document before
   application processing with the canonical form of the document result
   of the application processing.

   For example, a digital signature over the canonical form of an XML
   document or document subset would allow the signature digest
   calculations to be oblivious to changes in the original document's
   physical representation, provided that the changes are defined to be
   logically equivalent by the XML 1.0 or Namespaces in XML.  During
   signature generation, the digest is computed over the canonical form
   of the document.  The document is then transferred to the relying
   party, which validates the signature by reading the document and
   computing a digest of the canonical form of the received document.
   The equivalence of the digests computed by the signing and relying
   parties (and hence the equivalence of the canonical forms over which
   they were computed) ensures that the information content of the
   document has not been altered since it was signed.

1.3 Limitations

   Two XML documents may have differing information content that is
   nonetheless logically equivalent within a given application context.
   Although two XML documents are equivalent (aside from limitations
   given in this section) if their canonical forms are identical, it is
   not a goal of this work to establish a method such that two XML
   documents are equivalent if and only if their canonical forms are
   identical.  Such a method is unachievable, in part due to
   application-specific rules such as those governing unimportant



Boyer                        Informational                      [Page 4]

RFC 3076                     Canonical XML                    March 2001


   whitespace and equivalent data (e.g., <color>black</color> versus
   <color>rgb(0,0,0)</color>).  There are also equivalencies established
   by other W3C Recommendations and Working Drafts.  Accounting for
   these additional equivalence rules is beyond the scope of this work.
   They can be applied by the application or become the subject of
   future specifications.

   The canonical form of an XML document may not be completely
   operational within the application context, though the circumstances
   under which this occurs are unusual.  This problem may be of concern
   in certain applications since the canonical form of a document and
   the canonical form of the canonical form of the document are
   equivalent.  For example, in a digital signature application, the
   canonical form can be substituted for the original document without
   changing the digest calculation.  However, the security risk only
   occurs in the unusual circumstances described below, which can all be
   resolved or at least detected prior to digital signature generation.

   The difficulties arise due to the loss of the following information
   not available in the data model:

      1. base URI, especially in content derived from the replacement
         text of external general parsed entity references
      2. notations and external unparsed entity references
      3. attribute types in the document type declaration

   In the first case, note that a document containing a relative URI
   [URI] is only operational when accessed from a specific URI that
   provides the proper base URI.  In addition, if the document contains
   external general parsed entity references to content containing
   relative URIs, then the relative URIs will not be operational in the
   canonical form, which replaces the entity reference with internal
   content (thereby implicitly changing the default base URI of that
   content).  Both of these problems can typically be solved by adding
   support for the xml:base attribute [XBase] to the application, then
   adding appropriate xml:base attributes to document element and all
   top-level elements in external entities.  In addition, applications
   often have an opportunity to resolve relative URIs prior to the need
   for a canonical form.  For example, in a digital signature
   application, a document is often retrieved and processed prior to
   signature generation.  The processing SHOULD create a new document in
   which relative URIs have been converted to absolute URIs, thereby
   mitigating any security risk for the new document.

   In the second case, the loss of external unparsed entity references
   and the notations that bind them to applications means that canonical
   forms cannot properly distinguish among XML documents that
   incorporate unparsed data via this mechanism.  This is an unusual



Boyer                        Informational                      [Page 5]

RFC 3076                     Canonical XML                    March 2001


   case precisely because most XML processors currently discard the
   document type declaration, which discards the notation, the entity's
   binding to a URI, and the attribute type that binds the attribute
   value to an entity name.  For documents that must be subjected to
   more than one XML processor, the XML design typically indicates a
   reference to unparsed data using a URI in the attribute value.

   In the third case, the loss of attribute types can affect the
   canonical form in different ways depending on the type.  Attributes
   of type ID cease to be ID attributes.  Hence, any XPath expressions
   that refer to the canonical form using the id() function cease to
   operate.  The attribute types ENTITY and ENTITIES are not part of
   this case; they are covered in the second case above.  Attributes of
   enumerated type and of type ID, IDREF, IDREFS, NMTOKEN, NMTOKENS, and
   NOTATION fail to be appropriately constrained during future attempts
   to change the attribute value if the canonical form replaces the
   original document during application processing.  Applications can
   avoid the difficulties of this case by ensuring that an appropriate
   document type declaration is prepended prior to using the canonical
   form in further XML processing.  This is likely to be an easy task
   since attribute lists are usually acquired from a standard external
   DTD subset, and any entity and notation declarations not also in the
   external DTD subset are typically constructed from application
   configuration information and added to the internal DTD subset.

   While these limitations are not severe, it would be possible to
   resolve them in a future version of XML canonicalization if, for
   example, a new version of XPath were created based on the XML
   Information Set [Infoset] currently under development at the W3C.