diff options
Diffstat (limited to 'doc/rfc/rfc3653.txt')
| -rw-r--r-- | doc/rfc/rfc3653.txt | 843 |
1 files changed, 843 insertions, 0 deletions
diff --git a/doc/rfc/rfc3653.txt b/doc/rfc/rfc3653.txt new file mode 100644 index 0000000..a9f35f0 --- /dev/null +++ b/doc/rfc/rfc3653.txt @@ -0,0 +1,843 @@ + + + + + + +Network Working Group J. Boyer +Request for Comments: 3653 PureEdge Solutions +Category: Informational M. Hughes + Betrusted, Inc. + J. Reagle + W3C + December 2003 + + + XML-Signature XPath Filter 2.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 (2003). All Rights Reserved. + +Abstract + + XML Signature recommends a standard means for specifying information + content to be digitally signed and for representing the resulting + digital signatures in XML. Some applications require the ability to + specify a subset of a given XML document as the information content + to be signed. The XML Signature specification meets this requirement + with the XPath transform. However, this transform can be difficult + to implement efficiently with existing technologies. This + specification defines a new XML Signature transform to facilitate the + development of efficient document subsetting implementations that + interoperate under similar performance profiles. + + This document is the W3C XML Signature XPath-Filter 2.0 + 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. + + + + + + + + +Boyer, et al. Informational [Page 1] + +RFC 3653 XML-Signature XPath Filter 2.0 December 2003 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 + 1.1. Acknowledgements (Informative) . . . . . . . . . . . . 4 + 1.2. W3C Status . . . . . . . . . . . . . . . . . . . . . . 4 + 2. Terminology. . . . . . . . . . . . . . . . . . . . . . . . . 4 + 3. Specification of Signature Filter Transform. . . . . . . . . 5 + 3.1. Algorithm Identifier . . . . . . . . . . . . . . . . . 5 + 3.2. Syntax of Signature Filter Transform . . . . . . . . . 5 + 3.3. Input and Evaluation Context of Signature Filter + Transform. . . . . . . . . . . . . . . . . . . . . . . 7 + 3.4. Processing Model of Signature Filter Transform . . . . 7 + 4. Examples of Signature Filter Transform . . . . . . . . . . . 9 + 5. Normative References . . . . . . . . . . . . . . . . . . . . 13 + 6. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 14 + 7. Full Copyright Statement . . . . . . . . . . . . . . . . . . 15 + +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. + The XML Signature Recommendation [XML-DSig] defines standard means + for specifying information content to be digitally signed, including + the ability to select a portion of an XML document to be signed using + an XPath transform. + + This specification describes a new signature filter transform that, + like the XPath transform [XML-DSig, section 6.6.3], provides a method + for computing a portion of a document to be signed. In the interest + of simplifying the creation of efficient implementations, the + architecture of this transform is not based on evaluating an [XPath] + expression for every node of the XML parse tree (as defined by the + [XPath] data model). Instead, a sequence of XPath expressions is + used to select the roots of document subtrees -- location sets, in + the language of [XPointer] -- which are combined using set + intersection, subtraction and union, and then used to filter the + input node-set. The principal differences from the XPath transform + are: + + * A sequence of XPath operations can be executed in a single + transform, allowing complex filters to be more easily expressed + and optimized. + * The XPath expressions are evaluated against the input document + resulting in a set of nodes, instead of being used as a boolean + test against each node of the input node-set. + + + + + +Boyer, et al. Informational [Page 2] + +RFC 3653 XML-Signature XPath Filter 2.0 December 2003 + + + * To increase efficiency, the expansion of a given node to + include all nodes having the given node as an ancestor is now + implicit so it can be performed by faster means than the + evaluation of an XPath expression for each document node. + * The resulting node-sets can be combined using the three + fundamental set operations (intersection, subtraction, and + union), and then applied as a filter against the input node- + set, allowing operations such as signing an entire document + except for a specified subset, to be expressed more clearly and + efficiently. + + As with the original XPath transform, the primary purpose of this + transform is to ensure that only specifically defined changes to the + input XML document are permitted after the signature is affixed. + This can be done by excluding precisely those nodes that are allowed + to change once the signature is affixed, and including all other + input nodes in the output. It is the responsibility of the signature + filter transform author to ensure that nodes are not excluded which + could affect the interpretation of the transform output in the + application context. + + Consider the motivating scenario where an application wishes to affix + two enveloped signatures to the document; any other change to the + document must cause the signatures to be invalid. When the + application creates the first signature that signature is + automatically omitted from its own digest calculations. However, it + will also be necessary to exclude the subsequent (second) signature + element from the digest calculations of the first signature. This + specification can be used to efficiently satisfy this requirement + using the set subtraction operation. + + This transform also supports the ability to specify a set of nodes + that will be included in a signature, with all non-specified nodes + being excluded. This formulation is useful for isolating a portion + of a document, such as a chapter of a document, or a payload in a + protocol message, and can be expressed using the set intersection + operation. + + Complete familiarity with the first XML Signature XPath Transform + [XML-DSig, section 6.6.3] is required. + + NOTE: Since XPath Filter 2.0 depends on details of XPath, be sure to + take into account the XPath Errata at + <http://www.w3.org/1999/11/REC-xpath-19991116-errata>. + + + + + + + +Boyer, et al. Informational [Page 3] + +RFC 3653 XML-Signature XPath Filter 2.0 December 2003 + + +1.1. Acknowledgements (Informative) + + The following people provided valuable feedback that improved the + quality of this specification: + + * Christian Geuer-Pollmann, Universitat Siegen + * Donald Eastlake, 3rd, Motorola + * Gregor Karlinger, IAK TU Graz + * Aleksey Sanin + +1.2. W3C Status + + The World Wide Web Consortium Recommendation corresponding to this + RFC is at: + + http://www.w3.org/TR/xmldsig-filter2/ + +2. 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 BCP 14, RFC 2119 + [Keywords]. + + The XPath 1.0 Recommendation [XPath] defines the term node-set as + "(an unordered collection of nodes without duplicates)" 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). + + An input document is the document that contains all the nodes + available to processing by this transform. A document subset is a + portion of an XML document indicated by an XPath node-set, which may + not include all of the nodes in the document. For example, the input + node-set is a collection of XPath nodes from the input document that + is passed as a parameter to this transform. A subtree rooted by a + given node is a document subset containing the given node and every + node having the given node as an ancestor. Subtree expansion is the + process of expanding a node-set to include all subtrees rooted at any + node in the node-set. For example, the subtree expansion of a node- + set consisting of just a single element node would be a node-set + containing that element, its attribute nodes, namespace nodes, and + all its descendants including their attribute nodes and namespaces + nodes. + + The XML Signature Recommendation [XML-DSig] defines a reference as a + sequence of steps performed to obtain an octet stream to be digitally + signed. A transform is an identified algorithm to be used as a step + + + +Boyer, et al. Informational [Page 4] + +RFC 3653 XML-Signature XPath Filter 2.0 December 2003 + + + in the reference processing model. A transform takes an octet stream + or XPath node-set as input, and it produces an octet stream or XPath + node-set as output (the reference processing model automatically + converts the final output to an octet stream if it is an XPath node- + set). + +3. Specification of Signature Filter Transform + + The transform operates by computing a node-set that is used to filter + the input node-set: The output node-set consists of only those nodes + in both the input node-set and the filter node-set. In other words, + the output node-set is the intersection of the input node-set and the + computed filter node-set. + + The filter node-set is computed by evaluating a sequence of XPath + expressions and combining their results. A node-set is initially + computed containing the entire input document. In sequence, each + XPath expression is then evaluated, subtree-expanded, and then used + to transform the filter node-set according to a specified set + operation; intersection, subtraction, or union. After all XPaths + have been applied, the resulting node-set is used as the filter + node-set. + +3.1. Algorithm Identifier + + The XML Signature Recommendation [XML-DSig] uses a [URI] to identify + each algorithm to be performed when creating or validating a + signature. The signature filter transform is identified as follows: + + Algorithm Identifier + http://www.w3.org/2002/06/xmldsig-filter2 + +3.2. Syntax of Signature Filter Transform + + The signature filter transform shall be represented by a sequence of + one or more elements named XPath. The content of XPath is character + data containing an XPath expression. The XPath has an attribute + named Filter whose possible values are intersect, subtract, and + union. The Filter attribute indicates the set operation that is + performed with the resulting node-set when computing the filter + node-set. The following is an example of markup for a signature + filter that signs the entire input node-set except for elements with + identifier foo and bar (and all nodes with one of those elements as + an ancestor): + + <XPath Filter="subtract" + xmlns="http://www.w3.org/2002/06/xmldsig-filter2"> + id("foo bar") + + + +Boyer, et al. Informational [Page 5] + +RFC 3653 XML-Signature XPath Filter 2.0 December 2003 + + + </XPath> + + Schema Definition: + + <?xml version="1.0" encoding="utf-8"?> + <!DOCTYPE schema + + PUBLIC "-//W3C//DTD XMLSchema 200102//EN" + "http://www.w3.org/2001/XMLSchema.dtd" + [ + <!ATTLIST schema + xmlns:xf CDATA #FIXED 'http://www.w3.org/2002/06/xmldsig-filter2'> + <!ENTITY xf 'http://www.w3.org/2002/06/xmldsig-filter2'> + <!ENTITY % p ''> + <!ENTITY % s ''> + ]> + + <schema xmlns="http://www.w3.org/2001/XMLSchema" + xmlns:xf="http://www.w3.org/2002/06/xmldsig-filter2" + targetNamespace="http://www.w3.org/2002/06/xmldsig-filter2" + version="0.1" elementFormDefault="qualified"> + + <element name="XPath" + type="xf:XPathType"/> + + <complexType name="XPathType"> + <simpleContent> + <extension base="string"> + <attribute name="Filter"> + <simpleType> + <restriction base="string"> + <enumeration value="intersect"/> + <enumeration value="subtract"/> + <enumeration value="union"/> + </restriction> + </simpleType> + </attribute> + </extension> + </simpleContent> + </complexType> + + </schema> + + DTD: + + <!ELEMENT XPath (#PCDATA) > + <!ATTLIST XPath + Filter (intersect|subtract|union) #REQUIRED > + + + +Boyer, et al. Informational [Page 6] + +RFC 3653 XML-Signature XPath Filter 2.0 December 2003 + + +3.3. Input and Evaluation Context of Signature Filter Transform + + The input required by this transform is an XPath node-set over the + input document. If the input document is an octet stream, then the + application MUST convert the octet stream to an XPath node-set that + contains all of the document nodes (including comment nodes). The + evaluation context for the XPath expressions in the filter transform + will be: + + * A context node equal to the root node of the document whose + node-set was provided as input to this transform. The root + node is the parent of the document element and any comment and + processing instruction nodes outside of the document element. + * A context position, initialized to 1. + * A context size, initialized to 1. + * A library of functions equal to the function set defined in + [XPath] plus a function named here(). + * A set of variable bindings. No means for initializing these is + defined. Thus, the set of variable bindings used when + evaluating the XPath expression is empty, and use of a variable + reference in the XPath expression results in an error. + * The set of namespace declarations in scope for the XPath + element. + + The function here() is defined as follows: + + Function: node-set here() + + The here() function returns a node-set containing the attribute or + processing instruction node or the parent element of the text node + that directly bears the XPath expression. In this transform, this + will be the XPath element. This expression results in an error if + the containing XPath expression does not appear in the same XML + document against which the XPath expression is being evaluated. + +3.4. Processing Model of Signature Filter Transform + + Using the aforementioned evaluation context, the signature filter + transform evaluates the XPath expressions appearing in the character + content of the XPath elements and uses these to compute a filter + node-set F, which is then used to filter the input node-set I + resulting in an output node-set O: + + * Initialize the filter node-set F to consist of all nodes in the + input document. + * Iterate through each XPath expression, X, in sequence, and + update the filter node-set F as follows: + + + + +Boyer, et al. Informational [Page 7] + +RFC 3653 XML-Signature XPath Filter 2.0 December 2003 + + + o Evaluate the XPath expression X. The result is a node-set + S. + o Compute the set S' consisting of all nodes in the input + document that are either present in S or that have an + ancestor in S. This is equal to the union of all the + document subtrees rooted by a node in S. + o If the Filter attribute value is intersect, then compute the + intersection of the selected subtrees, S', with the filter + node-set F. The result will include only those nodes that + are in both the filter node-set and the selected subtrees: + F' = F INTERSECT S'. + o If the Filter attribute value is subtract, then compute the + subtraction of the selected subtrees, S', from the filter + node-set F. The result will include only those nodes that + are in the filter node-set, but not the selected subtrees: + F' = F - S'. + o Otherwise, if the Filter attribute value is union, then + compute the union the selected subtrees, S', with the filter + node-set F. The result will include all those nodes that + are in either the filter node-set, the selected subtrees, or + both: F' = F UNION S'. + o Update the filter node-set F to be the new node-set F'. + * Finally, after applying all the XPath expressions, compute the + output node-set O to be the intersection of the computed filter + node-set, F, with the input node-set, I. The result will + include all nodes from the input node-set that are also in the + filter node-set: O = I INTERSECT F. + * An empty input node-set will always result in an empty output + node-set. + + In this processing model, the conversion from a subtree + interpretation of the XPath expressions to a node-set containing all + nodes that must be used during the set operation, along with actual + performance of the set operation, is described explicitly. + Implementors SHOULD observe that it is possible to compute the + effective result of this operation in a single pass through the input + document without performing subtree expansion or any set operations: + + * For each XPath expression X, in sequence, evaluate the + expression and store the resulting node-set, S, along with the + associated set operation. + * Prepend a node-set consisting of just the document node, along + with the operation union. + * Create a new, empty filter node-set. + * Process each node in the input node-set document, adding each + node to the output node-set F if a flag Z is true. The flag is + computed as follows: + + + + +Boyer, et al. Informational [Page 8] + +RFC 3653 XML-Signature XPath Filter 2.0 December 2003 + + + o Z is true if and only if the node is present in any + subtree-expanded union node-set and all subsequent subtree- + expanded intersect node-sets but no subsequent subtree- + expanded subtract node-sets, or false otherwise. If there + are no subsequent intersect or subtract node-sets, then that + part of the test is automatically passed. + o Presence in a subtree-expanded node-set can be efficiently + determined without actually expanding the node-set, by + simply maintaining a stack or count that identifies whether + any nodes from that node-set are an ancestor of the node + being processed. + + Implementers MAY further observe that, if this transform is followed + by a canonicalization operation (e.g., [XML-C14N]), the described + filter computation can be efficiently commingled with the document- + order canonicalization processing. + +4. Examples of Signature Filter Transform + + The example below illustrates one way to create an enveloped + signature with the signature filter transform. The function here() + identifies the XPath element, and the subsequent location path + obtains the nearest ancestor Signature element. Due to the subtract + value of the Filter attribute, the output of the signature filter + transform is a node-set containing every node from the input node-set + except the nodes in the subtree rooted by the Signature element + containing the example signature filter transform below. + + <XPath Filter="subtract" + xmlns="http://www.w3.org/2002/06/xmldsig-filter2" + xmlns:dsig="http://www.w3.org/2000/09/xmldsig#"> + here()/ancestor::dsig:Signature[1] </XPath> + + A suitable signature reference URI to use with this subtract filter + would be URI="" (the entire signature document, without comments), + URI="#xpointer(/)" (the entire signature document, with comments) or + any same-document reference that includes the signature itself. + + An example of an intersect filter is a signature that co-signs + another signature. In this example, a Signature element identified + by PrimaryBorrowSig must be signed. The XPath expression obtains the + element node, and the transform expands the output node-set to + contain all nodes from the input node-set that are also in the + subtree rooted by the element node. + + <XPath Filter="intersect" + xmlns="http://www.w3.org/2002/06/xmldsig-filter2"> + id("PrimaryBorrowerSig") </XPath> + + + +Boyer, et al. Informational [Page 9] + +RFC 3653 XML-Signature XPath Filter 2.0 December 2003 + + + This type of intersect filter is useful for efficiently signing + subsets of a document, whether this is the same document as the + signature or an external document. For example, if the signature + reference URI is URI="document.xml", then this document will be + automatically parsed and just the identified element and its + descendants will be signed. + + Union filters, by themselves are of no particular use: The initial + filter node-set consists of the entire input document; any union with + this will have no effect, so the output of the transform will be + identical to the input. The union operation is intended to follow a + subtract operation, to allow a subtree to be removed, with the + exception of a lower subtree which is still included in the output. + + Consider the following document which contains a same-document + enveloped signature reference with an XPath filter containing three + + XPath operations: + + <Document> + <ToBeSigned> + <!-- comment --> + <Data /> + <NotToBeSigned> + <ReallyToBeSigned> + <!-- comment --> + <Data /> + </ReallyToBeSigned> + </NotToBeSigned> + </ToBeSigned> + <ToBeSigned> + <Data /> + <NotToBeSigned> + <Data /> + </NotToBeSigned> + </ToBeSigned> + <dsig:Signature + xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" + xmlns:dsig-xpath="http://www.w3.org/2002/06/xmldsig-filter2"> + <dsig:SignedInfo> + ... + <dsig:Reference URI=""> + <dsig:Transforms> + <dsig:Transform + Algorithm="http://www.w3.org/2002/06/xmldsig-filter2"> + <dsig-xpath:XPath + Filter="intersect"> //ToBeSigned </dsig-xpath:XPath> + <dsig-xpath:XPath + + + +Boyer, et al. Informational [Page 10] + +RFC 3653 XML-Signature XPath Filter 2.0 December 2003 + + + Filter="subtract"> //NotToBeSigned </dsig-xpath:XPath> + <dsig-xpath:XPath + Filter="union"> //ReallyToBeSigned </dsig-xpath:XPath> + </dsig:Transform> + </dsig:Transforms> + ... + </dsig:Reference> + </dsig:SignedInfo> + ... + </dsig:Signature> </Document> + + The intersect operation computes the intersection of the XPath- + selected subtrees with the filter node-set. In this case, the filter + node-set initially contains the entire input document, and the XPath + expression evaluates to the two ToBeSigned elements; these are + expanded to include all their descendents and intersected with the + filter node-set, resulting in the following: + + <ToBeSigned> + <!-- comment --> + <Data /> + <NotToBeSigned> + <ReallyToBeSigned> + <!-- comment --> + <Data /> + </ReallyToBeSigned> + </NotToBeSigned> + </ToBeSigned><ToBeSigned> + <Data /> + <NotToBeSigned> + <Data /> + </NotToBeSigned> + </ToBeSigned> + + The subtract filter computes the subtraction of the XPath-selected + subtrees from the filter node-set. In this case, the XPath + expression evaluates to the two NotToBeSigned elements; these are + expanded to include all their descendents and subtracted from the + filter node-set: + + <ToBeSigned> + <!-- comment --> + <Data /> + + </ToBeSigned><ToBeSigned> + <Data /> + + </ToBeSigned> + + + +Boyer, et al. Informational [Page 11] + +RFC 3653 XML-Signature XPath Filter 2.0 December 2003 + + + Next, the union filter computes the union of the XPath-selected + subtrees with the filter node-set. In this case, the XPath + expression evaluates to the ReallyToBeSigned element; this is + expanded to include all its descendents and added to the filter + node-set: + + <ToBeSigned> + <!-- comment --> + <Data /> + <ReallyToBeSigned> + <!-- comment --> + <Data /> + </ReallyToBeSigned> + </ToBeSigned><ToBeSigned> + <Data /> + + </ToBeSigned> + + Finally, this resulting filter node-set is used to transform the + input node-set. In this example, the input node-set is the entire + document, with comments removed. The transformed node-set will thus + be all those nodes from the input document, less comments, that are + also in the filter node-set: + + <ToBeSigned> + + <Data /> + <ReallyToBeSigned> + + <Data /> + </ReallyToBeSigned> + </ToBeSigned><ToBeSigned> + <Data /> + + </ToBeSigned> + + Note that the result contains no nodes that were not in the input + node-set. Although the filter node-set included comments, these were + not present in the input node-set so they are not present in the + output node-set. + + This signature filter does not provide any increased capability over + the original XPath transform. For example, this reference could be + replicated using the XPath transform as follows. + + <dsig:Reference URI=""> + <dsig:Transforms> + <dsig:Transform + + + +Boyer, et al. Informational [Page 12] + +RFC 3653 XML-Signature XPath Filter 2.0 December 2003 + + + Algorithm="http://www.w3.org/TR/1999/REC-xpath-19991116"> + <dsig:XPath> + (ancestor-or-self::ToBeSigned and + not (ancestor-or-self::NotToBeSigned)) + or ancestor-or-self::ReallyToBeSigned + </dsig:XPath> + </dsig:Transform> + </dsig:Transforms> + ... </dsig:Reference> + + The advantage of the signature filter transform over the XPath + transform is that the latter requires evaluation of a potentially- + complex expression against every node in the input set, which has + proved costly in practice for many useful operations. This + specification's filter requires evaluation of simple XPath + expressions and then the execution of some basic set operations or + their equivalent, which can be implemented significantly more + efficiently. + +5. Normative References + + [Keywords] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [URI] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform + Resource Identifiers (URI): Generic Syntax", RFC 2396, + August 1998. + + [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 + <http://www.w3.org/TR/2000/REC-xml-20001006>. + + [XML-C14N] Boyer, J., "Canonical XML", RFC 3076, March 2001. Also a + W3C Recommendation available at + <http://www.w3.org/TR/2001/REC-xml-c14n-20010315>. + + [XML-DSig] Eastlake, J., Reagle, J. and D. Solo, "XML-Signature + Syntax and Processing", RFC 3275, March 2002. Also a W3C + Recommendation available at + <http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/>. + + [XML-NS] "Namespaces in XML", T. Bray, D. Hollander, and A. + Layman. W3C Recommendation, January 1999. Available at + <http://www.w3.org/TR/1999/REC-xml-names-19990114/>. + + + + + + +Boyer, et al. Informational [Page 13] + +RFC 3653 XML-Signature XPath Filter 2.0 December 2003 + + + [XPath] "XML Path Language (XPath) Version 1.0", J. Clark and S. + DeRose. W3C Recommendation, November 1999. Available at + <http://www.w3.org/TR/1999/REC-xpath-19991116>. (Note + also XPath Errata at <http://www.w3.org/1999/11/REC- + xpath-19991116-errata>.) + + [XPointer] "XML Pointer Language (XPointer)", S. DeRose, R. Daniel, + and E. Maler. W3C Candidate Recommendation, January + 2001. Available at <http://www.w3.org/TR/2001/CR-xptr- + 20010911/>. + +6. Authors' Addresses + + John Boyer + PureEdge Solutions Inc. + 4396 West Saanich Rd. + Victoria, BC, Canada V8Z 3E9 + + Phone: +1-888-517-2675 + EMail: jboyer@PureEdge.com + + + Merlin Hughes + Betrusted, Inc. + 11000 Broken Land Parkway Suite 900 + Columbia, MD 21044 + + Phone: +1-443-367-7000 + EMail: Merlin.Hughes@betrusted.com + + + 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 + EMail: reagle@mit.edu + + + + + + + + + + + + +Boyer, et al. Informational [Page 14] + +RFC 3653 XML-Signature XPath Filter 2.0 December 2003 + + +7. Full Copyright Statement + + Copyright (C) The Internet Society (2003). 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 + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assignees. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Boyer, et al. Informational [Page 15] + |