Movatterモバイル変換

Abstract

Canonical XML Version 1.1 is a revisionto Canonical XML Version 1.0 to address issues related to inheritance ofattributes in the XML namespace when canonicalizing document subsets,including the requirement not to inheritxml:id, andto treatxml:base URI path processing properly.

Any XML 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[XML] and Namespaces in XML 1.0[Names]. This specification describes a method for generatinga physical representation, the canonical form, of an XML documentthat accounts for the permissible changes. Except for limitationsregarding a few unusual cases, if two documents have the same canonicalform, then the two documents are logically equivalent within thegiven application context. Note that two documents may have differingcanonical forms yet still be equivalent in a given context basedon application-specific equivalence rules for which no generalizedXML specification could account.

Canonical XML Version 1.1 is applicableto XML 1.0 and defined in terms of the XPath 1.0 data model. Itis not defined for XML 1.1.

Statusof this Document

This section describes the statusof this document at the time of its publication. Other documentsmay supersede this document. A list of current W3C publications andthe latest revision of this technical report can be found in theW3C technical reports index at http://www.w3.org/TR/.

This is aW3C Recommendation.

This document has been reviewed by W3C Members, by software developers, and by other W3C groups and interested parties, and is endorsed by the Director as a W3C Recommendation. It is a stable document and may be used as reference material or cited 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.

Comments on this document should be sent towww-xml-canonicalization-comments@w3.org which is an automaticallyarchived public email list.

Theimplementation report details CR implementation feedback fromseveral implementations. It should be noted that this IR reflectsresults implemented against the CR as clarified based on issues raisedduring the CR period and subsequently reflected in the wording ofthis Recommendation.

This document has been producedby theW3C XML Core WorkingGroup as part of the W3CXML Activity. The authors of this document are the members ofthe XML Core Working Group and invited experts from the Digital Signaturecommunity.

This document was produced by a group operatingunder the5 February 2004 W3C Patent Policy. W3C maintains apublic list of any patent disclosures made in connection withthe deliverables of the group; that page also includes instructionsfor disclosing a patent. An individual who has actual knowledge ofa patent which the individual believes contains Essential Claim(s) must disclose the information in accordancewith section 6 of the W3C Patent Policy.

The English versionof this specification is the only normative version.

Table of Contents

1. Introduction
   1. Terminology
   2. Applications
   3. Limitations
2. XML Canonicalization
   1. Data Model
   2. Document Order
   3. Processing Model
   4. Document Subsets
3. Examples of XML Canonicalization
   1. PIs, Comments, and Outside of DocumentElement
   2. Whitespace in DocumentContent
   3. Start and End Tags
   4. Character Modifications and CharacterReferences
   5. Entity References
   6. UTF-8 Encoding
   7. Document Subsets
   8. Document Subsets and XMLAttributes
4. Resolutions
   1. No XML Declaration
   2. No Character Model Normalization
   3. Handling of Whitespace Outside DocumentElement
   4. No Namespace Prefix Rewriting
   5. Order of Namespace Declarations and Attributes
   6. Superfluous Namespace Declarations
   7. Propagation of Default NamespaceDeclaration in Document Subsets
   8. Sorting Attributes by Namespace URI
5. References

1. Appendix

1 Introduction

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

Canonical XML Version 1.1is a revision to Canonical XML Version 1.0[C14N10] to addressissues related toinheritance of attributes in the XML namespace when canonicalizingdocument subsets, including the requirement not to inheritxml:id, and to treatxml:base URI path processingproperly. See also the Working Group Notes on[C14N-Issues] and[DSig-Usage] forfurther discussion of the relationship of Canonical XML Version 1.1 to CanonicalXML Version 1.0.

Canonical XML Version 1.1 is applicable to XML 1.0 and definedin terms of the XPath 1.0 data model. It is not defined for XML1.1.

1.1 Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALLNOT", "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 ofQName.

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

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

• The document is encoded inUTF-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 are removed
• Empty elements are converted to start-end tag pairs
• Whitespace outside of the document element and within start andend tags is normalized
• All whitespace in character content is retained (excluding charactersremoved during line feed normalization)
• Attribute value delimiters are set to quotation marks (doublequotes)
• Special characters in attribute values and character content arereplaced by character references
• Superfluous namespace declarations are removed from each element
• Default attributes are added to each element
• Fixup ofxml:base attributes[C14N-Issues] is performed
• Lexicographic order is imposed on the namespace declarations andattributes of each element

The termcanonical XML refers to XML that is in canonicalform. TheXML canonicalization method is the algorithm definedby this specification that generates the canonical form of a givenXML document or document subset. The termXML canonicalization refers to the process of applying the XML canonicalization methodto an XML document or document subset.

The XPath 1.0 Recommendation[XPath] defines the termnode-set and specifiesa data model for representing an input XML document as a set of nodesof various types (element, attribute, namespace, text, comment, processinginstruction, and root). The nodes are included in or excluded froma 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 shouldbe rendered in the canonical form (in this sense, it is used as aformal mathematical set). A node that is excluded from the set isnot rendered in the canonical form being generated, even if its parentnode is included in the node-set. However, an omitted node may stillimpact the rendering of its descendants (e.g. by augmenting the namespacecontext of the descendants or supplying a base URI throughxml:base).

1.2 Applications

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

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

Note: Although not stated as a requirement on implementations, norformally proved to be the case, it is the intent of thisspecification that if the text generated by canonicalizing adocument according to this specification is itself parsed andcanonicalized according to this specification, the text generated bythe second canonicalization will be the same as that generated bythe first canonicalization.

1.3 Limitations

Two XML documents may have differing information content thatis nonetheless logically equivalent within a given application context.Although two XML documents are equivalent (aside from limitationsgiven in this section) if their canonical forms are identical, itis not a goal of this work to establish a method such that two XMLdocuments are equivalent ifand only if their canonical formsare identical. Such a method is unachievable, in part due to application-specificrules such as those governing unimportant whitespace and equivalentdata (e.g.<color>black</color> versus<color>rgb(0,0,0)</color>). There are also equivalencies established by other W3C Recommendationsand Working Drafts. Accounting for these additional equivalence rulesis beyond the scope of this work. They can be applied by the applicationor become the subject of future specifications.

The canonicalform of an XML document may not be completely operational within theapplication context, though the circumstances under which this occursare unusual. This problem may be of concern in certain applicationssince the canonical form of a document and the canonical form of thecanonical form of the document are equivalent. For example, in a digitalsignature application, it cannot be established whether the operationaloriginal document or the non-operational canonical form was signedbecause the canonical form can be substituted for the original documentwithout changing the digest calculation. However, the security riskonly occurs in the unusual circumstances described below, which canall be resolved or at least detected prior to digital signature generation.

The difficulties arise due to the loss of the following informationnot available in thedata model:

1. base URI, especially in content derived from the replacement textof 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 relativeURI[URI] is only operational when accessed froma specific URI that provides the proper base URI. In addition, ifthe document contains external general parsed entity references tocontent containing relative URIs, then the relative URIs will notbe operational in the canonical form, which replaces the entity referencewith internal content (thereby implicitly changing the default baseURI of that content). Both of these problems can typically be solvedby adding support for thexml:base attribute[XBase] to the application, then adding appropriatexml:base attributes to document element and all top-levelelements in external entities. In addition, applications often havean opportunity to resolve relative URIs prior to the need for a canonicalform. For example, in a digital signature application, a documentis often retrieved and processed prior to signature generation. Theprocessing SHOULD create a new document in which relative URIs havebeen converted to absolute URIs, thereby mitigating any security riskfor the new document.

In the second case, the loss of externalunparsed entity references and the notations that bind them to applicationsmeans that canonical forms cannot properly distinguish among XML documentsthat incorporate unparsed data via this mechanism. This is an unusualcase precisely because most XML processors currently discard the documenttype declaration, which discards the notation, the entity's bindingto a URI, and the attribute type that binds the attribute value toan entity name. For documents that must be subjected to more thanone XML processor, the XML design typically indicates a referenceto unparsed data using a URI in the attribute value.

In thethird case, the loss of attribute types can affect the canonical formin different ways depending on the type. Attributes of type ID, otherthan thexml:id attribute, cease to be ID attributes.Hence, any XPath expressions that refer to the canonical form usingtheid() function cease to operate. The attribute typesENTITY and ENTITIES are not part of this case; they are covered inthe second case above. Attributes of enumerated type and of type ID,IDREF, IDREFS, NMTOKEN, NMTOKENS, and NOTATION fail to be appropriatelyconstrained during future attempts to change the attribute value ifthe canonical form replaces the original document during applicationprocessing. Applications can avoid the difficulties of this case byensuring that an appropriate document type declaration is prependedprior to using the canonical form in further XML processing. Thisis likely to be an easy task since attribute lists are usually acquiredfrom a standard external DTD subset, and any entity and notation declarationsnot also in the external DTD subset are typically constructed fromapplication configuration information and added to the internal DTDsubset.

While these limitations are not severe, it would bepossible to resolve them in a future version of XML canonicalizationif, for example, a new version of XPath were created based on theXML Information Set[Infoset] currently underdevelopment at the W3C.

2 XML Canonicalization

2.1 Data Model

The data model defined in the XPath 1.0 Recommendation[XPath] is used to represent the input XML documentor document subset. Implementations SHOULD but need not be based onan XPath implementation. XML canonicalization is defined in termsof the XPath definition of a node-set, and implementations MUST produceequivalent results.

The first parameter of input to the XMLcanonicalization method is either an XPath node-set or an octet streamcontaining a well-formed XML document. Implementations MUST supportthe octet stream input and SHOULD also support the document subsetfeature via node-set input. For the purpose of describing canonicalizationin terms of an XPath node-set, this section describes how an octetstream is converted to an XPath node-set.

The second parameter of input to the XML canonicalizationmethod is a boolean flag indicating whether or not comments shouldbe included in the canonical form output by the XML canonicalizationmethod. If a canonical form contains comments corresponding tothe comment nodes in the input node-set, the result is calledcanonicalXML with comments. Note that the XPath data model does not createcomment nodes for comments appearing within the document type declaration.Implementations are REQUIRED to be capable of producing canonicalXML excluding all comments that may have appeared in the input documentor document subset. Support for canonical XML with comments is RECOMMENDED.

If an XML document must be converted to a node-set, XPath REQUIRESthat an XML processor be used to create the nodes of its data modelto fully represent the document. The XML processor performs the followingtasks in order:

1. normalize line feeds
2. normalize attribute values
3. replace CDATA sections with their character content
4. resolve character and parsed entity references

The input octet stream MUST contain a well-formed XML document,but the input need not be validated. However, the attribute valuenormalization and entity reference resolution MUST be performed inaccordance with the behaviors of a validating XML processor. As well,nodes for default attributes (declared in the ATTLIST with anAttValue but notspecified) are created in each element. Thus, the declarations inthe document type declaration are used to help create the canonicalform, even though the document type declaration is not retained inthe canonical form.

The XPath data model represents data usingUCS characters. Implementations MUST use XML processors that supportUTF-8 andUTF-16 and translateto the UCS character domain. For UTF-16, the leading byte order markis treated as an artifact of encoding and stripped from the UCS characterdata (subsequent zero width non-breaking spaces appearing within theUTF-16 data are not removed)[UTF-16, Section 3.2]. Support forISO-8859-1 encoding is RECOMMENDED,and all other character encodings are OPTIONAL.

All whitespacewithin the root document element MUST be preserved (except for any#xD characters deleted by line delimiter normalization). This includesall whitespace in external entities. Whitespace outside of the rootdocument element MUST be discarded.

In the XPath data model,there exist the following node types: root, element, comment, processinginstruction, text, attribute and namespace. There exists a singleroot node whose children are processing instruction nodes and commentnodes to represent information outside of the document element (andoutside of the document type declaration). The root node also hasa single element node representing the top-level document element.Each element node can have child nodes of type element, text, processinginstruction, and comment. The attributes and namespaces associatedwith an element are not considered to be child nodes of the element,but they are associated with the element by inclusion in the element'sattribute and namespace axes. Note that attribute and namespace axesmay not directly correspond to the text appearing in the element'sstart tag in the original document.

Note: An elementhas attribute nodes to represent the non-namespace attribute declarationsappearing in its start tagas well as nodes to represent thedefault attributes.

By virtue of the XPath data model, XMLcanonicalization is namespace-aware[Names]. However, it cannot and therefore does not account for namespaceequivalencies using namespace prefix rewriting (seeexplanation in Section 4). In theXPath data model, each element and attribute has a name returned bythe functionname() which can, at the discretion of theapplication, be the QName appearing in the original document. XMLcanonicalization REQUIRES that the XML processor retain sufficientinformation such that the QName of the element as it appeared in theoriginal document can be provided.

Note: An elementE has namespace nodes that represent its namespace declarationsas well as any namespace declarations made by its ancestors thathave not been overridden inE's declarations, the defaultnamespace if it is non-empty, and the declaration of the prefixxml.

Note: This specification supports the recentXML plenary decision to deprecate relativenamespace URIs as follows: implementations of XML canonicalizationMUST report an operation failure on documents containing relativenamespace URIs. XML canonicalization MUST NOT be implemented withan XML parser that converts relative URIs to absolute URIs.

Character content is represented in the XPath data model with textnodes. All consecutive characters are placed into a single text node.Furthermore, the text node's characters are represented in the UCScharacter domain. The XML canonicalization method does not performcharacter model normalization (seeexplanationin Section 4). However, the XML processor used to prepare theXPath data model input is REQUIRED to use Unicode Normalization FormC [NFC,NFC-Corrigendum] when converting an XML document to the UCS character domain fromany encoding that is not UCS-based (currently, UCS-based encodingsinclude UTF-8, UTF-16, UTF-16BE, and UTF-16LE, UCS-2, and UCS-4).

Since XML canonicalization converts an XPath node-set into acanonical form, the first parameter MUST either be an XPath node-setor it must be converted from an octet stream to a node-set by performingthe XML processing necessary to create the XPath nodes described above,then setting an initial XPath evaluation context of:

• Acontext node, initialized to the root node of the inputXML document.
• Acontext position, initialized to 1.
• Acontext size, initialized to 1.
• Anylibrary of functions conforming to the XPath Recommendation.
• An empty set ofvariable bindings.
• An empty set ofnamespace declarations.

and evaluating the following default expression: