idnits 2.17.1 draft-ietf-xmldsig-requirements-03.txt: -(499): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == There are 2 instances of lines with non-ascii characters in the document. == 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. ** There are 35 instances of too long lines in the document, the longest one being 1 character in excess of 72. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (August 01, 2000) is 8662 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'XML' on line 241 looks like a reference -- Missing reference section? 'Charter' on line 293 looks like a reference -- Missing reference section? 'XLink' on line 138 looks like a reference -- Missing reference section? 'RDF' on line 203 looks like a reference -- Missing reference section? 'Oslo' on line 190 looks like a reference -- Missing reference section? 'DOMHASH' on line 164 looks like a reference -- Missing reference section? 'XML-C14N' on line 164 looks like a reference -- Missing reference section? 'XML-namespaces' on line 171 looks like a reference -- Missing reference section? 'Xlink' on line 178 looks like a reference -- Missing reference section? 'XPointer' on line 185 looks like a reference -- Missing reference section? 'Berners-Lee' on line 234 looks like a reference -- Missing reference section? 'WebData' on line 194 looks like a reference -- Missing reference section? 'Brown' on line 264 looks like a reference -- Missing reference section? 'WS-summary' on line 248 looks like a reference -- Missing reference section? 'IOTP' on line 283 looks like a reference -- Missing reference section? 'XFA' on line 285 looks like a reference -- Missing reference section? 'XFDL' on line 285 looks like a reference -- Missing reference section? 'XML-fragment' on line 299 looks like a reference Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 20 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 XML Digital Signatures Working Group J. Reagle, 2 INTERNET-DRAFT W3C/MIT 3 draft-ietf-xmldsig-requirements-03.txt 4 Expires August 01, 2000 6 XML Signature Requirements 8 Copyright Notice 10 Copyright (c) 2000 The Internet Society & W3C (MIT, INRIA, Keio), All 11 Rights Reserved. 13 IETF Status of this Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet Engineering Task 19 Force (IETF), its areas, and its working groups. Note that other 20 groups may also distribute working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet- Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 W3C Status of this document 35 This document is a production of the joint IETF/W3C XML Signature 36 Working Group. 38 http://www.w3.org/Signature 40 The comparable html draft of this version may be found at 42 http://www.w3.org/TR/2000/xmldsig-requirements-20000104/ 44 The latest version of this document series may be found at: 46 http://www.w3.org/TR/xmldsig-core 48 This Working Draft of XML Signature Requirements is a very stable 49 result of this Working Draft that has been advanced through W3C Last 50 Call and has been published as an IETF Informational RFC. The only 51 changes from the previous version were those necessary to comply with 52 RFC Editor publication requirements, including the addition of a 53 security considerations section. 55 Please send comments to the editor and cc: the list 56 . Publication as a Working Draft does not 57 imply endorsement by the W3C membership. This is a draft document and 58 may be updated, replaced or obsoleted by other documents at any time. 59 It is inappropriate to cite W3C Drafts as other than "work in 60 progress". A list of current W3C working drafts can be found at 61 http://www.w3.org/TR 63 Patent disclosures relevant to this specification may be found on the 64 WG's patent disclosure page. 66 Abstract 68 This document lists the design principles, scope, and requirements for 69 the XML Digital Signature specification. It includes requirements as 70 they relate to the signature syntax, data model, format, cryptographic 71 processing, and external requirements and coordination. 73 Table of Contents 75 1. Introduction 76 2. Design Principles and Scope 77 3. Requirements 78 3.1. Signature Data Model and Syntax 79 3.2. Format 80 3.3. Cryptography and Processing 81 3.4 Coordination 82 4. Security Considerations 83 5. References 84 6. Acknowledgements 85 7. Author's Address 86 8. Full Copyright Statements 88 1. Introduction 90 The XML 1.0 Recommendation [XML] describes the syntax of a class of 91 data objects called XML documents. The mission of this working group 92 is to develop a XML syntax used for representing signatures on digital 93 content and procedures for computing and verifying such signatures. 94 Signatures will provide data integrity, authentication, and/or 95 non-repudiatability. 97 This document lists the design principles, scope, and requirements 98 over three things: (1) the scope of work available to the WG, (2) the 99 XML signature specification, and (3) applications that implement the 100 specification. It includes requirements as they relate to the 101 signature syntax, data model, format, cryptographic processing, and 102 external requirements and coordination. Those things that are required 103 are designated as "must," those things that are optional are 104 designated by "may," those things that are optional but recommended 105 are designated as "should." 107 2. Design Principles and Scope 108 1. The specification must describe how to sign digital content, and 109 XML content in particular. The XML syntax used to represent a 110 signature (over any content) is described as an XML Signature. 111 [Charter] 112 2. XML Signatures are generated from a hash over the canonical form 113 of a signature manifest. (In this document we use the term 114 manifest to mean a collection of references to the objects being 115 signed. The specifications may use the terms manifest, package or 116 other terms differently from this document while still meeting 117 this requirement.) The manifest must support references to Web 118 resources, the hash of the resource content (or its canonicalized 119 form), and (optionally) the resource content type. [Brown, 120 List(Solo)] Web resources are defined as any digital content that 121 can be addressed using the syntax of XLink locator [XLink]). 122 3. The meaning of a signature is simple: The XML Signature syntax 123 associates the content of resources listed in a manifest with a 124 key via a strong one-way transformation. 125 1. The XML Signature syntax must be extensible such that it can 126 support arbitrary application/trust semantics and assertion 127 capabilities -- that can also be signed. 128 [Charter(Requirement1&4), List(Bugbee, Solo)] 129 2. The WG is not chartered to specify trust semantics, but 130 syntax and processing rules necessary for communicating 131 signature validity (authenticity, integrity and 132 non-repudiation). [Charter(Requirement1)] At the Chairs' 133 discretion and in order to test the extensibility of the 134 syntax, the WG may produce non-critical-path proposals 135 defining common semantics (e.g., manifest, package, 136 timestamps, endorsement, etc.) relevant to signed assertions 137 about Web resources in a schema definition [XML, RDF] or link 138 type definition [XLink]. 139 Comment: A more formal definition of a signed resource is below. 140 The notation is "definition(inputs):constraints" where definition 141 evaluates as true for the given inputs and specified constraints. 142 signed-resource(URI-of-resource, content, key, signature): (there 143 was some protocol message at a specific time such that 144 "GET(URI-of-resource) = content") AND (sign-doc(content, key, 145 sig)) 146 sign-doc(content, key, signature): signature is the value of a 147 strong one-way transformation over content and key that yields 148 content integrity/validity and/or key non-repudiability 149 4. The specification must not specify methods of confidentiality 150 though the Working Group may report on the feasibility of such 151 work in a future or rechartered activity. [List(Bugbee)] 152 5. The specification must only require the provision of key 153 information essential to checking the validity of the 154 cryptographic signature. For instance, identity and key recovery 155 information might be of interest to particular applications, but 156 they are not within the class of required information defined in 157 this specification. [List(Reagle)] 158 6. The specification must define or reference at least one method of 159 canonicalizing and hashing the signature syntax (i.e., the 160 manifest and signature blocks). [Oslo] The specification must not 161 specify methods of canonicalizing resource content [Charter], 162 though it may specify security requirements over such methods. 163 [Oslo] Such content is normalized by specifying an appropriate 164 content C14N (canonicalization) algorithm [DOMHASH, XML-C14N]. 165 Applications are expected to normalize application specific 166 semantics prior to handing data to a XML Signature application or 167 specify the necessary transformations for this process within the 168 signature. [Charter] 169 7. XML Signature applications must be conformant with the 170 specifications as follows: 171 1. XML-namespaces [XML-namespaces] within its own signature 172 syntax. Applications may choose C14N algorithms which do or 173 do not process namespaces within XML content. For instance, 174 some C14N algorithms may opt to remove all namespace 175 declarations, others may rewrite namespace declarations to 176 provide for context independent declarations within every 177 element. 178 2. XLink [Xlink] within its own signature syntax. For any 179 resource identification beyond simple URIs (without fragment 180 IDs) or fragmentIDs, applications must use XLink locators to 181 reference signed resources. Signature applications must not 182 embed or expand XLink references in signed content, though 183 applications may choose C14N algorithms which provide this 184 feature. 185 3. XML-Pointers [XPointer] within its own signature syntax. If 186 applications reference/select parts of XML documents, they 187 must use XML-Pointer within an XLink locator. [WS-list(1)] 188 The WG may specify security requirements that constrain the 189 operation of these dependencies to ensure consistent and secure 190 signature generation and operation. [Oslo] 191 8. XML Signatures must be developed as part of the broader Web design 192 philosophy of decentralization, URIs, Web data, 193 modularity/layering/extensibility, and assertions as statements 194 about statements. [Berners-Lee, WebData] In this context, existing 195 cryptographic provider (and infrastructure) primitives should be 196 taken advantage of. [List(Solo)] 198 3. Requirements 200 3.1 Signature Data Model and Syntax 202 1. XML Signature data structures must be based on the RDF data model 203 [RDF] but need not use the RDF serialization syntax. [Charter] 204 2. XML Signatures apply to any resource addressable by a locator -- 205 including non-XML content. XML Signature referents are identified 206 with XML locators (URIs or fragments) within the manifest that 207 refer to external or internal resources (i.e., network accessible 208 or within the same XML document/package). [Berners-Lee, Brown, 209 List(Vincent), WS, XFDL] 210 3. XML Signatures must be able to apply to a part or totality of a 211 XML document. [Charter, Brown] 212 Comment: A related requirement under consideration is requiring 213 the specification to support the ability to indicate those 214 portions of a document one signs via exclusion of those portions 215 one does not wish to sign. This feature allows one to create 216 signatures that have document closure [List(Boyer(1)], retain 217 ancestor information, and retain element order of non-continuous 218 regions that must be signed. We are considering implementing this 219 requirement via (1) a special element, (2) an 220 exclude list accompanying the resource locator, or (3) the 221 XML-Fragment or XPointer specifications -- or a requested change 222 to those specifications if the functionality is not available. See 223 List(Boyer(1,2)) for further discussion of this issue. 224 4. Multiple XML Signatures must be able to exist over the static 225 content of a Web resource given varied keys, content 226 transormations, and algorithm specifications (signature, hash, 227 canonicalization, etc.). [Charter, Brown] 228 5. XML Signatures are first class objects themselves and consequently 229 must be able to be referenced and signed. [Berners-Lee] 230 6. The specification must permit the use of varied digital signature 231 and message authentication codes, such as symmetric and asymmetric 232 authentication schemes as well as dynamic agreement of keying 233 material. [Brown] Resource or algorithm identifier are a first 234 class objects, and must be addressable by a URI. [Berners-Lee] 235 7. XML Signatures must be able to apply to the original version of an 236 included/encoded resource. [WS-list (Brown/Himes)] 238 3.2 Format 240 1. An XML Signature must be an XML element (as defined by production 241 39 of the XML1.0 specification. [XML]) 242 2. When XML signatures are placed within a document the operation 243 must preserve (1) the document's root element tag as root and (2) 244 the root's descendancy tree except for the addition of signature 245 element(s) in places permitted by the document's content model. 246 For example, an XML form, when signed, should still be 247 recognizable as a XML form to its application after it has been 248 signed. [WS-summary] 249 3. XML Signature must provide a mechanism that facilitates the 250 production of composite documents -- by addition or deletion -- 251 while preserving the signature characteristics (integrity, 252 authentication, and non-repudiatability) of the consituent parts. 253 [Charter, Brown, List(Bugbee)] 254 4. An important use of XML Signatures will be detached Web 255 signatures. However, signatures may be embedded within or 256 encapsulate XML or encoded content. [Charter] This WG must specify 257 a simple method of packaging and encapsulation if no W3C 258 Recommendation is available. 260 3.3 Cryptography and Processing 262 1. The specification must permit arbitrary cryptographic signature 263 and message authentication algorithms, symmetric and asymmetric 264 authentication schemes, and key agreement methods. [Brown] 265 2. The specification must specify at least one mandatory to implement 266 signature canonicalization, content canonicalization, hash, and 267 signature algorithm. 268 3. In the event of redundant attributes within the XML Signature 269 syntax and relevant cryptographic blobs, XML Signature 270 applications prefer the XML Signature semantics. 271 Comment: Another possibility is that an error should be generated, 272 however it isn't where a conflict will be flagged between the 273 various function and application layers regardless. 274 4. The signature design and specification text must not permit 275 implementers to erroneously build weak implementations susceptible 276 to common security weaknesses (such as as downgrade or algorithm 277 substitution attacks). 279 3.4 Coordination 281 1. The XML Signature specification should meet the requirements of 282 the following applications: 283 1. Internet Open Trading Protocol v1.0 [IOTP] 284 2. Financial Services Mark Up Language v2.0 [Charter] 285 3. At least one forms application [XFA, XFDL] 286 2. To ensure that all requirements within this document are 287 adequately addressed, the XML Signature specification must be 288 reviewed by a designated member of the following communities: 289 1. XML Syntax Working Group: canonicalization dependencies. 290 [Charter] 291 2. XML Linking Working Group: signature referants. [Charter] 292 3. XML Schema Working Group: signature schema design. [Charter] 293 4. Metadata Coordination Group: data model design. [Charter] 294 5. W3C Internationalization Interest Group: [AC Review] 295 6. XML Package Working Group: signed content in/over packages. 296 7. XML Fragment Working Group: signing portions of XML content. 297 Comment: Members of the WG are very interested in signing and 298 processing XML fragments and packaged components. Boyer asserts 299 that [XML-fragment] does not "identify non-contiguous portions of 300 a document in such a way that the relative positions of the 301 connected components is preserved." Packaging is a capability 302 critical to XML Signature applications, but it is clearly 303 dependent on clear trust/semantic definitions, package application 304 requirements, and even cache-like application requirements. It is 305 not clear how this work will be addressed. 307 4. Security Considerations 309 This document lists XML Digital Signature requirements as they relate 310 to the signature syntax, data model, format, cryptographic processing, 311 and external requirements and coordination. In that context much of 312 this document is about security. 314 5. References 316 AC Review 317 Misha Wolf. "The Charter should include the I18N WG in the 318 section on 'Coordination with Other Groups.'" 319 http://lists.w3.org/Archives/Team/xml-dsig-review/1999May/0007. 320 html 322 Berners-Lee 323 Axioms of Web Architecture: URIs. 324 http://www.w3.org/DesignIssues/Axioms.html 325 Web Architecture from 50,000 feet 326 http://www.w3.org/DesignIssues/Architecture.html 328 Brown-XML-DSig 329 Internet Draft. Digital Signatures for XML 330 http://www.w3.org/Signature/Drafts/xmldsig-signature- 331 990618.html 333 Charter 334 XML Signature (xmldsig) Charter. 335 http://www.w3.org/1999/05/XML-DSig-charter-990521.html 337 DOMHASH 338 Internet Draft. Digest Values for DOM (DOMHASH) 339 http://www.ietf.org/internet-drafts/draft-ietf-trade- 340 hiroshi-dom-hash-03.txt 342 FSML 343 FSML 1.5 Reference Specification 344 http://www.echeck.org/library/ref/fsml-v1500a.pdf 346 Infoset-Req 347 XML Information Set Requirements Note. 348 http://www.w3.org/TR/1999/NOTE-xml-infoset-req-19990218.html 350 IOTP 351 Internet Open Trading Protocol v1.0 352 http://www.ietf.org/internet-drafts/draft-ietf-trade-iotp-v1.0- 353 protocol-07.txt 355 IOTP-DSig 356 Internet Draft. Digital Signatures for the Internet Open 357 Trading Protocol 358 http://www.ietf.org/internet-drafts/draft-ietf-trade-iotp-v1.0- 359 dsig-05.txt 361 Oslo 362 Minutes of the XML Signature WG Sessions at IETF face-to-face 363 meeting in Oslo. 365 RDF 366 RDF Schema 367 http://www.w3.org/TR/1999/PR-rdf-schema-19990303 368 RDF Model and Syntax 369 http://www.w3.org/TR/1999/REC-rdf-syntax-19990222 371 Signature WG List 372 http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/ 374 URI 375 Uniform Resource Identifiers (URI): Generic Syntax 376 http://www.ietf.org/rfc/rfc2396.txt 378 WS (list, summary) 379 XML-DSig '99: The W3C Signed XML Workshop 380 http://www.w3.org/DSig/signed-XML99/ 381 http://www.w3.org/DSig/signed-XML99/summary.html 383 XLink 384 XML Linking Language 385 http://www.w3.org/1999/07/WD-xlink-19990726 387 XML 388 Extensible Markup Language (XML) Recommendation. 389 http://www.w3.org/TR/1998/REC-xml-19980210 391 XML-C14N 392 XML Canonicalization Requirements. 393 http://www.w3.org/TR/1999/NOTE-xml-canonical-req-19990605 395 XFA 396 XML Forms Architecture (XFA) 397 http://www.w3.org/Submission/1999/05/ 399 XFDL 400 Extensible Forms Description Language (XFDL) 4.0 401 http://www.w3.org/Submission/1998/16/ 403 XML-Fragment 404 XML-Fragment Interchange 405 http://www.w3.org/1999/06/WD-xml-fragment-19990630.html 407 XML-namespaces 408 Namespaces in XML 409 http://www.w3.org/TR/1999/REC-xml-names-19990114 411 XML-schema 412 XML Schema Part 1: Structures 413 http://www.w3.org/1999/05/06-xmlschema-1/ 414 XML Schema Part 2: Datatypes 415 http://www.w3.org/1999/05/06-xmlschema-2/ 417 XPointer 418 XML Pointer Language (XPointer) 419 http://www.w3.org/1999/07/WD-xptr-19990709 421 WebData 422 Web Architecture: Describing and Exchanging Data. 423 http://www.w3.org/1999/04/WebData 425 6. Acknowledgements 427 This document was produced as a collaborative work item of the XML 428 Signature (xmldsig) Working Group. 430 7. Author's Address 432 Joseph M. Reagle Jr., W3C 433 XML Signature Co-Chiar 434 Massachusetts Institute of Technology 435 Laboratory for Computer Science 436 W3C, NE43-350 437 545 Technology Square 438 Cambridge, MA 02139 439 Phone: 1.617.258.7621 440 E-Mail: reagle@w3.org 441 URL: http://www.w3.org/People/Reagle 443 8. Full Copyright Statements 445 The terms of use of this document is governed by either the IETF 446 or W3C terms. The reader must comply with either the complete 447 IETF or W3C terms but need not comply with both. 449 IETF 451 Copyright (C) The Internet Society (date). All Rights Reserved. 453 This document and translations of it may be copied and furnished 454 to others, and derivative works that comment on or otherwise 455 explain it or assist in its implementation may be prepared, copied, 456 published and distributed, in whole or in part, without 457 restriction of any kind, provided that the above copyright notice 458 and this paragraph are included on all such copies and derivative 459 works. However, this document itself may not be modified in any 460 way, such as by removing the copyright notice or references to the 461 Internet Society or other Internet organizations, except as needed 462 for the purpose of developing Internet standards in which case the 463 procedures for copyrights defined in the Internet Standards 464 process must be followed, or as required to translate it into 465 languages other than English. 467 The limited permissions granted above are perpetual and will not 468 be revoked by the Internet Society or its successors or assigns. 470 This document and the information contained herein is provided on 471 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 472 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 473 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 474 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 475 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 477 W3C http://www.w3.org/Consortium/Legal/copyright-documents-19990405 479 Copyright � 1995-1999 World Wide Web Consortium, (Massachusetts 480 Institute of Technology, Institut National de Recherche en 481 Informatique et en Automatique, Keio University). All Rights Reserved. 482 http://www.w3.org/Consortium/Legal/ 484 Public documents on the W3C site are provided by the copyright holders 485 under the following license. The software or Document Type Definitions 486 (DTDs) associated with W3C specifications are governed by the Software 487 Notice. By using and/or copying this document, or the W3C document 488 from which this statement is linked, you (the licensee) agree that you 489 have read, understood, and will comply with the following terms and 490 conditions: 492 Permission to use, copy, and distribute the contents of this document, 493 or the W3C document from which this statement is linked, in any medium 494 for any purpose and without fee or royalty is hereby granted, provided 495 that you include the following on ALL copies of the document, or 496 portions thereof, that you use: 497 1. A link or URL to the original W3C document. 498 2. The pre-existing copyright notice of the original author, if it 499 doesn't exist, a notice of the form: "Copyright � World Wide Web 500 Consortium, (Massachusetts Institute of Technology, Institut 501 National de Recherche en Informatique et en Automatique, Keio 502 University). All Rights Reserved. 503 http://www.w3.org/Consortium/Legal/" (Hypertext is preferred, but 504 a textual representation is permitted.) 505 3. If it exists, the STATUS of the W3C document. 507 When space permits, inclusion of the full text of this NOTICE should 508 be provided. We request that authorship attribution be provided in any 509 software, documents, or other items or products that you create 510 pursuant to the implementation of the contents of this document, or 511 any portion thereof. 513 No right to create modifications or derivatives of W3C documents is 514 granted pursuant to this license. However, subsequent to additional 515 requirements documented in the Copyright FAQ, modifications or 516 derivatives are sometimes granted by the W3C to individuals complying 517 with those terms. 519 THIS DOCUMENT IS PROVIDED "AS IS," AND COPYRIGHT HOLDERS MAKE NO 520 REPRESENTATIONS OR WARRANTIES, EXPRESS OR IMPLIED, INCLUDING, BUT NOT 521 LIMITED TO, WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR 522 PURPOSE, NON-INFRINGEMENT, OR TITLE; THAT THE CONTENTS OF THE DOCUMENT 523 ARE SUITABLE FOR ANY PURPOSE; NOR THAT THE IMPLEMENTATION OF SUCH 524 CONTENTS WILL NOT INFRINGE ANY THIRD PARTY PATENTS, COPYRIGHTS, 525 TRADEMARKS OR OTHER RIGHTS. 527 COPYRIGHT HOLDERS WILL NOT BE LIABLE FOR ANY DIRECT, INDIRECT, SPECIAL 528 OR CONSEQUENTIAL DAMAGES ARISING OUT OF ANY USE OF THE DOCUMENT OR THE 529 PERFORMANCE OR IMPLEMENTATION OF THE CONTENTS THEREOF. 531 The name and trademarks of copyright holders may NOT be used in 532 advertising or publicity pertaining to this document or its contents 533 without specific, written prior permission. Title to copyright in this 534 document will at all times remain with copyright holders.