idnits 2.17.00 (12 Aug 2021) /tmp/idnits51524/draft-ietf-xmldsig-xc14n-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([XML-C14N]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The "Author's Address" (or "Authors' Addresses") section title is misspelled. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 2003) is 6725 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'URI' is defined on line 626, but no explicit reference was found in the text == Unused Reference: 'XML-schema' is defined on line 660, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2396 (ref. 'URI') (Obsoleted by RFC 3986) -- Possible downref: Non-RFC (?) normative reference: ref. 'XML' ** Downref: Normative reference to an Informational RFC: RFC 3076 (ref. 'XML-C14N') -- Possible downref: Non-RFC (?) normative reference: ref. 'XML-DSig' -- Possible downref: Non-RFC (?) normative reference: ref. 'XML-Fragment' -- Possible downref: Non-RFC (?) normative reference: ref. 'XInclude' -- Possible downref: Non-RFC (?) normative reference: ref. 'XML-NS' -- Possible downref: Non-RFC (?) normative reference: ref. 'XML-Enc' -- Possible downref: Non-RFC (?) normative reference: ref. 'XML-schema' -- Possible downref: Non-RFC (?) normative reference: ref. 'XPath' Summary: 8 errors (**), 0 flaws (~~), 4 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT John Boyer 2 PureEdge Solutions 3 Donald E. Eastlake 3rd 4 Motorola 5 Joseph Reagle 6 W3C 7 Expires: June 2004 December 2003 9 Exclusive XML Canonicalization, Version 1.0 10 --------- --- ----------------- ------- --- 11 13 Status of This Document 15 Distribution of this draft is unlimited. Comments should be sent to 16 the XMLDSIG working group mailing list or to the authors. 18 This document is an Internet Draft and is in full conformance with 19 all provisions of Section 10 of RFC 2026. Internet Drafts are 20 working documents of the Internet Engineering Task Force (IETF), its 21 areas, and its working groups. Note that other groups may also 22 distribute working documents as Internet Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 Copyright Notice 37 Copyright (C) 2003 The Internet Society & W3C (MIT, INRIA, Keio), All 38 Rights Reserved. 40 Abstract 42 Canonical XML [XML-C14N] specifies a standard serialization of XML 43 that, when applied to a subdocument, includes the subdocument's 44 ancestor context including all of the namespace declarations and 45 attributes in the "xml:" namespace. However, some applications 46 require a method which, to the extent practical, excludes ancestor 47 context from a canonicalized subdocument. For example, one might 48 require a digital signature over an XML payload (subdocument) in an 49 XML message that will not break when that subdocument is removed from 50 its original message and/or inserted into a different context. This 51 requirement is satisfied by Exclusive XML Canonicalization. 53 W3C Status of this document 55 W3C Recommendation 18 July 2002 57 This version: 58 http://www.w3.org/TR/2002/REC-xml-exc-c14n-20020718/ 59 Latest version: 60 http://www.w3.org/TR/xml-exc-c14n/ 62 This document is the W3C (World Wide Web Consortium) Exclusive 63 Canonicalization Recommendation. This document has been reviewed by 64 W3C Members and other interested parties and has been endorsed by the 65 Director as a W3C Recommendation. It is a stable document and may be 66 used as reference material or cited as a normative reference from 67 another document. W3C's role in making the Recommendation is to draw 68 attention to the specification and to promote its widespread 69 deployment. This enhances the functionality and interoperability of 70 the Web. 72 Table of Contents 74 Status of This Document....................................1 75 Copyright Notice...........................................1 77 Abstract...................................................2 78 W3C Status of this document................................2 80 Table of Contents..........................................3 82 1. Introduction............................................4 83 1.1 Terminology............................................4 84 1.2 Applications...........................................6 85 1.3 Limitations............................................6 86 2. The Need for Exclusive XML Canonicalization.............7 87 2.1 A Simple Example.......................................7 88 2.2 General Problems with re-Enveloping....................8 89 3. Specification of Exclusive XML Canonicalization........10 90 3.1 Constrained Implementation (non-normative)............11 91 4. Use in XML Security....................................12 92 5. Security Considerations................................13 93 5.1 Target Context........................................13 94 5.2 'Esoteric' Node-sets..................................14 95 6. References.............................................14 96 7. Acknowledgements (Informative).........................15 98 Authors Addresses.........................................16 100 Full Copyright Statement..................................17 101 Expiration and File Name..................................17 103 1. Introduction 105 The XML Recommendation [XML] specifies the syntax of a class of 106 objects called XML documents. The Namespaces in XML Recommendation 107 [XML-NS] specifies additional syntax and semantics for XML documents. 108 It is normal for XML documents and subdocuments which are equivalent 109 for the purposes of many applications to differ in their physical 110 representation. For example, they may differ in their entity 111 structure, attribute ordering, and character encoding. The goal of 112 this specification is to establish a method for serializing the XPath 113 node-set representation of an XML document or subset such that: 115 1. The node-set is minimally affected by any XML context which has 116 been omitted. 117 2. The canonicalization of a node-set representing well-balanced 118 XML [XML-Fragment] will be unaltered by further applications of 119 exclusive canonicalization. 120 3. It can be determined whether two node-sets are identical except 121 for transformations considered insignificant by this 122 specification under [XML, XML-NS]. 124 An understanding of the Canonical XML Recommendation [XML-C14N] is 125 required. 127 1.1 Terminology 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 131 document are to be interpreted as described in RFC 2119 [Keywords]. 133 The XPath 1.0 Recommendation [XPath] defines the term node-set and 134 specifies a data model for representing an input XML document as a 135 set of nodes of various types (element, attribute, namespace, text, 136 comment, processing instruction, and root). The nodes are included in 137 or excluded from a node-set based on the evaluation of an expression. 138 Within this specification and [XML-C14N], a node-set is used to 139 directly indicate whether or not each node should be rendered in the 140 canonical form (in this sense, it is used as a formal mathematical 141 set). A node that is excluded from the set is not rendered in the 142 canonical form being generated, even if its parent node is included 143 in the node-set. However, an omitted node may still impact the 144 rendering of its descendants (e.g. by affecting the namespace context 145 of the descendants). 147 A document subset is a portion of an XML document indicated by an 148 XPath node-set that may not include all of the nodes in the document. 149 As defined in [XPath] every node (e.g., element, attribute, and 150 namespace), has exactly one parent, which is either an element node 151 or the root node. An apex node is an element node in a document 152 subset having no element node ancestor in the document subset. An 153 orphan node is an element node whose parent element node is not in 154 the document subset. The output parent of an orphan node that is not 155 an apex node is the nearest ancestor element of the orphan node that 156 is in the document subset; an apex node has no output parent. The 157 output parent of a non-orphan node is the parent of the node. An 158 output ancestor is any ancestor element node in the document subset. 160 For example given a document tree with three generations under the 161 root node A and where capitalization denotes the node is in the 162 document subset (A,E,G). 164 Pictorial Representation: 166 [diagram of nodes, 167 http://www.w3.org/TR/xml-exc-c14n/exc-c14n.png] 169 Textual Representation: 171 A-+-b 172 `-c-+-d 173 `-E-+-f 174 `-G 175 The following characteristics apply: 177 * A is an apex node, output parent of E, and output ancestor of 178 (E,G); 179 * E is an orphan node and the output parent of G. 181 An element E in a document subset visibly utilizes a namespace 182 declaration, i.e. a namespace prefix P and bound value V, if E or an 183 attribute node in the document subset with parent E has a qualified 184 name in which P is the namespace prefix. A similar definition applies 185 for an element E in a document subset that visibly utilizes the 186 default namespace declaration, which occurs if E has no namespace 187 prefix. 189 The namespace axis of an element contains nodes for all non-default 190 namespace declarations made within the element as well as non-default 191 namespace declarations inherited from ancestors of the element. The 192 namespace axis also contains a node representing the default 193 namespace if it is not the empty string, whether the default 194 namespace was declared within the element or by an ancestor of the 195 element. Any subset of the nodes in a namespace axis can be included 196 in a document subset. 198 The method of canonicalization described in this specification 199 receives an InclusiveNamespaces PrefixList parameter, which lists 200 namespace prefixes that are handled in the manner described by the 201 Canonical XML Recommendation [XML-C14N]. 203 The exclusive canonical form of a document subset is a physical 204 representation of the XPath node-set, as an octet sequence, produced 205 by the method described in this specification. It is as defined in 206 the Canonical XML Recommendation [XML-C14N] except for the changes 207 summarized as follows: 209 * attributes in the XML namespace, such as xml:lang and xml:space 210 are not imported into orphan nodes of the document subset, and 211 * namespace nodes that are not on the InclusiveNamespaces 212 PrefixList are expressed only in start tags where they are visible 213 and if they are not in effect from an output ancestor of that tag. 215 The term exclusive canonical XML refers to XML that is in exclusive 216 canonical form. The exclusive XML canonicalization method is the 217 algorithm defined by this specification that generates the exclusive 218 canonical form of a given XML document subset. The term exclusive XML 219 canonicalization refers to the process of applying the exclusive XML 220 canonicalization method to an XML document subset. 222 1.2 Applications 224 The applications of Exclusive XML Canonicalization are very similar 225 to those for Canonical XML [XML-C14N]. However, exclusive 226 canonicalization, or equivalent means of excluding most XML context, 227 is necessary for signature applications where the XML context of 228 signed XML will change. This sort of change is typical of many 229 protocol applications. 231 Note that in the case of the SignedInfo element of [XML-DSig], the 232 specification of an appropriate canonicalization method is the only 233 technique available to protect the signature from insignificant 234 changes in physical form and changes in XML context. 236 1.3 Limitations 238 Exclusive XML Canonicalization has the limitations of Canonical XML 239 [XML-C14N] plus two additional limitations as follows: 241 1. The XML being canonicalized may depend on the effect of XML 242 namespace attributes, such as xml:lang, xml:space, and xml:base 243 appearing in ancestor nodes. To avoid problems due to the non- 244 importation of such attributes into an enveloped document 245 subset, either they MUST be explicitly given in a node of the 246 XML document subset being canonicalized where their effect is 247 needed or which is an ancestor of the node where their effect is 248 needed or they MUST always be declared with an equivalent value 249 in every context in which the XML document subset will be 250 interpreted. 251 2. Applications that use the XML being canonicalized may depend on 252 the effect of XML namespace declarations where the namespace 253 prefix being bound is not visibly utilized. An example would be 254 an attribute whose value is an XPath expression and whose 255 evaluation therefore depends upon namespace prefixes referenced 256 in the expression. Or, an attribute value might be considered a 257 QName [XML-NS] by some applications, but it is only a string- 258 value to XPath: 260 10.09. 262 To avoid problems with such namespace declarations, 264 o the XML MUST be modified so that use of the namespace prefix 265 involved is visible, or 266 o the namespace declarations MUST appear and be bound to the 267 same values in every context in which the XML will be 268 interpreted, or 269 o the prefixes for such namespaces MUST appear in the 270 InclusiveNamespaces PrefixList. 272 2. The Need for Exclusive XML Canonicalization 274 In some cases, particularly for signed XML in protocol applications, 275 there is a need to canonicalize a subdocument in such a way that it 276 is substantially independent of its XML context. This is because, in 277 protocol applications, it is common to envelope XML in various layers 278 of message or transport elements, to strip off such enveloping, and 279 to construct new protocol messages, parts of which were extracted 280 from different messages previously received. If the pieces of XML in 281 question are signed, they need to be canonicalized in a way such that 282 these operations do not break the signature but the signature still 283 provides as much security as can be practically obtained. 285 2.1 A Simple Example 287 As a simple example of the type of problem that changes in XML 288 context can cause for signatures, consider the following document: 290 291 content 292 294 this is then enveloped in another document: 296 297 298 content 299 300 302 The first document above is in canonical form. But assume that 303 document is enveloped as in the second case. The subdocument with 304 elem1 as its apex node can be extracted from this second case with an 305 XPath expression such as: 307 (//. | //@* | //namespace::*)[ancestor-or-self::n1:elem1] 309 The result of applying Canonical XML to the resulting XPath node-set 310 is the following (except for line wrapping to fit this document): 312 314 content 315 317 Note that the n0 namespace has been included by Canonical XML because 318 it includes namespace context. This change which would break a 319 signature over elem1 based on the first version. 321 2.2 General Problems with re-Enveloping 323 As a more complete example of the changes in canonical form that can 324 occur when the enveloping context of a document subset is changed, 325 consider the following document: 327 329 331 332 333 335 And the following which has been produced by changing the enveloping 336 of elem2: 338 343 345 346 347 349 Assume an XPath node-set produced from each case by applying the 350 following XPath expression: 352 (//. | //@* | //namespace::*)[ancestor-or-self::n1:elem2] 354 Applying Canonical XML to the node-set produced from the first 355 document yields the following serialization (except for line wrapping 356 to fit in this document): 358 362 363 365 However, although elem2 is represented by the same octet sequence in 366 both pieces of external XML above, the Canonical XML version of elem2 367 from the second case would be (except for line wrapping so it will 368 fit into this document) as follows: 370 374 375 377 Note that the change in context has resulted in lots of changes in 378 the subdocument as serialized by the inclusive Canonical XML [XML- 379 C14N]. In the first example, n0 had been included from the context 380 and the presence of an identical n3 namespace declaration in the 381 context had elevated that declaration to the apex of the 382 canonicalized form. In the second example, n0 has gone away but n2 383 has appeared, n3 is no longer elevated, and an xml:space declaration 384 has appeared, due to changes in context. But not all context changes 385 have effect. In the second example, the presence at ancestor nodes of 386 an xml:lang and n1 prefix namespace declaration have no effect 387 because of existing declarations at the elem2 node. 389 On the other hand, using Exclusive XML Canonicalization as specified 390 herein, the physical form of elem2 as extracted by the XPath 391 expression above is (except for line wrapping so it will fit into 392 this document) as follows: 394 396 397 399 in both cases. 401 3. Specification of Exclusive XML Canonicalization 403 The data model, processing, input parameters, and output data for 404 Exclusive XML Canonicalization are the same as for Canonical XML 405 [XML-C14N] with the following exceptions: 407 1. Canonical XML applied to a document subset requires the search 408 of the ancestor nodes of each orphan element node for attributes 409 in the XML namespace, such as xml:lang and xml:space. These are 410 copied into the element node except if a declaration of the same 411 attribute is already in the attribute axis of the element 412 (whether or not it is included in the document subset). This 413 search and copying are omitted from the Exclusive XML 414 Canonicalization method. 415 2. The Exclusive XML Canonicalization method may receive an 416 additional, possibly null, parameter InclusiveNamespaces 417 PrefixList containing a list of namespace prefixes and/or a 418 token indicating the presence of the default namespace. All 419 namespace nodes appearing on this list are handled as provided 420 in Canonical XML [XML-C14N]. 421 3. A namespace node N with a prefix that does not appear in the 422 InclusiveNamespaces PrefixList is rendered if all of the 423 conditions are met: 424 1. Its parent element is in the node-set, and 425 2. it is visibly utilized by its parent element, and 426 3. the prefix has not yet been rendered by any output 427 ancestor, or the nearest output ancestor of its parent 428 element that visibly utilizes the namespace prefix does not 429 have a namespace node in the node-set with the same 430 namespace prefix and value as N. 431 4. If the token representing the default namespace is not present 432 in InclusiveNamespaces PrefixList, then the rules for rendering 433 xmlns="" are changed as follows. When canonicalizing the 434 namespace axis of an element E that is in the node-set, output 435 xmlns="" if and only if all of the conditions are met: 436 1. E visibly utilizes the default namespace (i.e., it has no 437 namespace prefix), and 438 2. it has no default namespace node in the node-set, and 439 3. the nearest output ancestor of E that visibly utilizes the 440 default namespace has a default namespace node in the node- 441 set. 443 (This step for for xmlns="" is necessary because it is not 444 represented in the XPath data model as a namespace node, but as 445 the absence of a namespace node; see Section 4.7 Propagation of 446 Default Namespace Declaration in Document Subsets [XML-C14N].) 448 3.1 Constrained Implementation (non-normative) 450 The following is a (non-normative) method for implementing the 451 Exclusive XML Canonicalization method for many straightforward cases 452 -- it assumes a well-formed subset and that if an element is in the 453 node-set, so is all of its namespace axis; if the element is not in 454 the subset, neither is its namespace axis. 456 1. Recursively process the entire tree (from which the XPath node- 457 set was selected) in document order starting with the root. (The 458 operation of copying ancestor xml: namespace attributes into 459 output apex element nodes is not done.) 460 2. If the node is not in the XPath subset, continue to process its 461 children element nodes recursively. 462 3. If the element node is in the XPath subset then output the node 463 in accordance with Canonical XML except for namespace nodes 464 which are rendered as follows: 465 1. ns_rendered is a copy of a dictionary, off the top of the 466 state stack, of prefixes and their values which have 467 already been rendered by an output ancestor of the 468 namespace node's parent element. 469 2. Render each namespace node if and only if all of the 470 conditions are met: 471 1. it is visibly utilized by the immediate parent element 472 or one of its attributes, or is present in 473 InclusiveNamespaces PrefixList, and 474 2. its prefix and value do not appear in ns_rendered. 475 3. Render xmlns="" if and only if all of the conditions are 476 met: 477 1. The default namespace is visibly utilized by the 478 immediate parent element node, or the default prefix 479 token is present in InclusiveNamespaces PrefixList, 480 and 481 2. the element does not have a namespace node in the 482 node-set declaring a value for the default namespace, 483 and 484 3. the default namespace prefix is present in the 485 dictionary ns_rendered. 486 4. Insert all the rendered namespace nodes (including 487 xmlns="") into the ns_rendered dictionary, replacing any 488 existing entries. Push ns_rendered onto the state stack and 489 recurse. 490 5. After the recursion returns, pop the state stack. 492 4. Use in XML Security 494 Exclusive Canonicalization may be used as a Transform or 495 CanonicalizationMethod algorithm in XML Digital Signature [XML-DSig] 496 and XML Encryption [XML-Enc]. 498 Identifier: 499 http://www.w3.org/2001/10/xml-exc-c14n# 501 http://www.w3.org/2001/10/xml-exc-c14n#WithComments 503 Just as with [XML-C14N] one may use the "#WithComments" parameter to 504 include the serialization of XML comments. This algorithm also takes 505 an optional explicit parameter of an empty InclusiveNamespaces 506 element with a PrefixList attribute. The value of this attribute is a 507 white space delimited list of namespace prefixes, and where #default 508 indicates the default namespace, to be handled as per [XML-C14N]. The 509 list is in NMTOKENS format (a white space separated list). For 510 example: 512 514 516 518 indicates the exclusive canonicalization transform, but that 519 namespaces with prefix "dsig" or "soap" and default namespaces should 520 be processed according to [XML-C14N]. 522 Schema Definition: 524 525 531 532 533 534 ]> 536 541 543 544 545 546 548 DTD: 549 550 553 5. Security Considerations 555 This specification is used to serialize an XPath node-set under 556 certain assumptions given in [XML-C14N] and this specification. Three 557 such examples include: 559 1. implementations of [XML-C14N] and this specification do not 560 render an XML declaration; 561 2. implementations of this specification only render attributes 562 from the "XML" namespace (e.g., xml:lang, xml:space, and 563 xml:base) when they are in the subset being serialized; 564 3. implementations of this specification do not consider the 565 appearance of a namespace prefix within an attribute value to be 566 visibly utilized. 568 While such choices are consistent with other XML specifications and 569 satisfy the Working Group's application requirements it is important 570 that an XML application carefully construct its transforms such that 571 the result is meaningful and unambiguous in its application context. 572 In addition to this section, the Limitations of this specification, 573 the Resolutions of [XML-C14N], and the Security Considerations of 574 [XML-DSig] should be carefully attended to. 576 5.1 Target Context 578 The requirement of this specification is to satisfy applications that 579 "require a method which, to the extent practical, excludes ancestor 580 context from a canonicalized subdocument." Given a fragment being 581 removed from its source instance, this specification satisfies this 582 requirement by excluding from the fragment any context from its 583 ancestors that is not utilized. Consequently, a signature [XML-DSig] 584 over that fragment will remain valid in its source context, removed 585 from the source context, and even in a new target context. However, 586 this specification does not insulate the fragment against confused 587 interpretation in a target context. 589 For example, if the element is signed in its source instance 590 of and then removed and placed in the target 591 instance , the 592 signature should still be valid, but won't be if is 593 interprated as belonging to the http://example.org/bar namespace: 594 this is dependent on how nodes are processed. 596 This specification does not define mechanisms of removing, inserting, 597 and "fixing up" a node-set. (For an example of this sort of 598 specification, see the processing required of Creating the Result 599 Infoset (section 4.5) when an [XInclude] is performed.) Instead, 600 applications must carefully specify the XML (i.e., source, fragment, 601 and target) or define the node-set processing (i.e., removal, 602 replacement, and insertion) with respect to default namespace 603 declarations (e.g., xmlns="") and XML attributes (e.g., xml:lang, 604 xml:space, and xml:base). 606 5.2 'Esoteric' Node-sets 608 Consider an application that might use this specification or [XML- 609 C14N] to serialize a single attribute node. An implementation of 610 either specification will not emit a namespace declaration for that 611 single attribute node. Consequently, a "carefully constructed" 612 transform should create a node-set containing the attribute and the 613 relevant namespace declaration for serialization. 615 This example is provided to caution that as one moves beyond well- 616 formed [XML] and then well-balanced XML [XML-Fragment], it becomes 617 increasingly difficult to create a result that "is meaningful and 618 unambiguous in its application context." 620 6. References 622 [Keywords] - RFC 2119. Key words for use in RFCs to Indicate 623 Requirement Levels. S. Bradner. Best Current Practice, March 1997. 624 Available at http://www.ietf.org/rfc/rfc2119.txt 626 [URI] - RFC 2396 . Uniform Resource Identifiers (URI): Generic 627 Syntax. T. Berners-Lee, R. Fielding, and L. Masinter. Standards 628 Track, August 1998. Available at http://www.ietf.org/rfc/rfc2396.txt 630 [XML] - Extensible Markup Language (XML) 1.0 (Second Edition). T. 631 Bray, E. Maler, J. Paoli, and C. M. Sperberg-McQueen. W3C 632 Recommendation, October 2000. Available at 633 http://www.w3.org/TR/2000/REC-xml-20001006 . 635 [XML-C14N] - RFC 3076. "Canonical XML", J. Boyer, March 2001. Also a 636 W3C Recommendation available at http://www.w3.org/TR/2001/REC-xml- 637 c14n-20010315 639 [XML-DSig] - XML-Signature Syntax and Processing. D. Eastlake, J. 640 Reagle, and D. Solo. IETF Draft Standard/W3C Recommendation, August 641 2001. Available at http://www.w3.org/TR/2002/REC-xmldsig- 642 core-20020212/ 644 [XML-Fragment] - XML Fragment Interchange. P. Grosso, and D. 645 Veillard. W3C Candidate Recommendation, February 2001. Available at 646 http://www.w3.org/TR/2001/CR-xml-fragment-20010212 648 [XInclude] - XML Inclusions (XInclude) Version 1.0. J. Marsh, and D. 649 Orchad. W3C Candidate Recommendation, February 2002. Available at 650 http://www.w3.org/TR/2002/CR-xinclude-20020221/ 652 [XML-NS] - Namespaces in XML. T. Bray, D. Hollander, and A. Layman. 653 W3C Recommendation, January 1999. Available at 654 http://www.w3.org/TR/1999/REC-xml-names-19990114/ 656 [XML-Enc] - XML Encryption Syntax and Processing. D. Eastlake, and J. 657 Reagle. W3C Candidate Recommendation, March 2002. Available at 658 http://www.w3.org/TR/2002/CR-xmlenc-core-20020304/ 660 [XML-schema] - XML Schema Part 1: Structures D. Beech, M. Maloney, N. 661 Mendelsohn, and H. Thompson. W3C Recommendation, May 2001. Available 662 at http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/ 664 [XPath] - XML Path Language (XPath) Version 1.0. J. Clark and S. 665 DeRose. W3C Recommendation, November 1999. Available at 666 http://www.w3.org/TR/1999/REC-xpath-19991116. 668 7. Acknowledgements (Informative) 670 The following people provided valuable feedback that improved the 671 quality of this specification: 673 * Merlin Hughes, Baltimore 674 * Thomas Maslen, DSTC 675 * Paul Denning, MITRE 676 * Christian Geuer-Pollmann, University Siegen 677 * Bob Atkinson, Microsoft 679 Authors Addresses 681 John Boyer 682 PureEdge Solutions Inc. 683 4396 West Saanich Rd. 684 Victoria, BC, Canada V8Z 3E9 686 Phone: 1-888-517-2675 687 EMail: jboyer@PureEdge.com 689 Donald E. Eastlake 3rd 690 Motorola 691 155 Beaver Street 692 Milford, MA 01757 USA 694 Telephone: +1-508-634-2066 (h) 695 +1-508-786-7554 (w) 696 EMail: Donald.Eastlake@motorola.com 698 Joseph M. Reagle Jr., W3C 699 Massachusetts Institute of Technology 700 Laboratory for Computer Science 701 NE43-350, 545 Technology Square 702 Cambridge, MA 02139 704 Phone: +1.617.258.7621 705 EMail: reagle@mit.edu 707 Full Copyright Statement 709 Copyright (C) 2003 The Internet Society & W3C (MIT, INRIA, Keio), All 710 Rights Reserved. 712 This document and translations of it may be copied and furnished to 713 others, and derivative works that comment on or otherwise explain it 714 or assist in its implementation may be prepared, copied, published 715 and distributed, in whole or in part, without restriction of any 716 kind, provided that the above copyright notice and this paragraph are 717 included on all such copies and derivative works. However, this 718 document itself may not be modified in any way, such as by removing 719 the copyright notice or references to the Internet Society or other 720 Internet organizations, except as needed for the purpose of 721 developing Internet standards in which case the procedures for 722 copyrights defined in the Internet Standards process must be 723 followed, or as required to translate it into languages other than 724 English. 726 The limited permissions granted above are perpetual and will not be 727 revoked by the Internet Society or its successors or assigns. 729 This document and the information contained herein is provided on an 730 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 731 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 732 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 733 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 734 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 736 Expiration and File Name 738 This draft expires June 2004. 740 Its file name is draft-ietf-xmldsig-xc14n-02.txt.