idnits 2.17.1 draft-fhirsch-xml-mime-security-00.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 is more than 15 pages and seems to lack a Table of Contents. == 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 10 instances of too long lines in the document, the longest one being 9 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 117: '...ned according to this protocol MUST be...' RFC 2119 keyword, line 151: '...Digital Signature and MUST include one...' RFC 2119 keyword, line 193: '... XML identifiers (URIs) be REQUIRED as...' RFC 2119 keyword, line 196: '...mendation. SHA-1 MUST be specified as...' RFC 2119 keyword, line 286: '...ence. XML content MUST be UTF8, if it...' (5 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 175 has weird spacing: '...ecurity signa...' == Line 194 has weird spacing: '...llowing diges...' == Line 333 has weird spacing: '...veloped signa...' == Line 501 has weird spacing: '...ons for a dis...' -- 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 (October 1, 2001) is 8240 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) == Unused Reference: '2' is defined on line 510, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 513, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 535, but no explicit reference was found in the text ** Downref: Normative reference to an Historic RFC: RFC 1848 (ref. '2') ** Downref: Normative reference to an Informational RFC: RFC 3076 (ref. '3') ** Obsolete normative reference: RFC 3075 (ref. '4') (Obsoleted by RFC 3275) -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '7' ** Obsolete normative reference: RFC 3023 (ref. '8') (Obsoleted by RFC 7303) -- Possible downref: Non-RFC (?) normative reference: ref. '9' ** Obsolete normative reference: RFC 2629 (ref. '10') (Obsoleted by RFC 7749) Summary: 11 errors (**), 0 flaws (~~), 9 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group F. Hirsch 3 Internet-Draft Zolera Systems, Inc. 4 Expires: April 1, 2002 October 1, 2001 6 XML Security for Multipart MIME: Multipart/Signed and 7 Multipart/Encrypted 8 draft-fhirsch-xml-mime-security-00 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on April 1, 2002. 33 Copyright Notice 35 Copyright (C) The Internet Society (2001). All Rights Reserved. 37 Abstract 39 This draft defines how XML Digital Signatures and XML Encryption may 40 be used with Multipart MIME security to provide MIME integrity and 41 confidentiality. It extends RFC 1847 by defining 42 application/signature+xml and application/encryption+xml protocols 43 for the Multipart/Signed and Multipart/Encrypted MIME types. 44 Although non-XML content may be signed or encrypted based on XML 45 signing and encryption, additional capabilities are available for XML 46 MIME content. This draft defines a signature transform parameter for 47 partial signing or manipulation of XML MIME content as well as 48 processing rules in addition to the XML Digital Signature and XML 49 Encryption processing rules. 51 1. Introduction 53 RFC 1847 [1] defines a general mechanism for security multiparts in 54 MIME, defining the Multipart/Signed and Multipart/Encrypted types. 55 This mechanism uses a protocol parameter to specify the signature or 56 encryption mechanism. Multipart/Signed enables the first MIME part 57 to contain arbitrary MIME content and the second to contain a 58 signature over that content. Common mail applications currently use 59 application/x-pkcs7-signature as the signing protocol, creating a 60 PKCS#7 signature in the signature part. Multipart/Encrypted uses the 61 first part to contain encryption control information, and the second 62 part encrypted content. An alternative to Multipart/Encrypted is to 63 pass a single MIME part containing encrypted content using using 64 application/x-pkcs7-mime, as done by common mail applications. 66 XML Digital Signature [4] and XML Encryption [5] recommendations 67 enable signing and encryption of arbitary content as well as 68 providing advanced support for XML content. This includes the 69 ability to sign or encrypt portions of XML, reference multiple 70 objects in a signature and include metadata information with signed 71 or encrypted content. XML signatures support multiple signatures, 72 useful when content is routed for approvals. Both XML Signatures and 73 Encryption support inclusion of the signature or encrypted content in 74 the orginal XML document, creating a close binding. Signatures may 75 also be separate from the signed content, especially useful when the 76 content is large or binary and would interfere with XML processing of 77 the signature. Likewise, encrypted cipherdata may be included in an 78 XML encrypted element or managed separately. 80 Combining the XML security mechanisms with Multipart MIME security 81 enables MIME applications to benefit from XML security as well as 82 enabling XML security to use a defined mechanism for handling 83 multiple parts. This draft extends the existing Multipart MIME 84 security mechanism by defining two new protocol parameters to be used 85 with RFC 1847, application/signature+xml and 86 application/encryption+xml. These names follow the XML naming 87 convention defined in RFC 3023, XML Media Types [8]. This draft 88 defines these parameters and a minimal set of processing rules. 90 2. Multipart Security 92 Multipart Security (RFC 1847) defines multipart MIME types specific 93 for security - Multipart/Signed and Multipart/Encrypted. The 94 definitions of these types include the definition of required MIME 95 parameters, and the parts which comprise these multipart definitions. 97 Each type requires a boundary parameter used to separate the parts of 98 the multipart message, as common with multipart MIME. Each also 99 requires definition of a MIME protocol, defined as a type/subtype. 100 This draft defines two protocols for use with MIME multipart 101 security: application/signature+xml and application/encryption+xml. 102 These are defined using the type "application" (rather than "text") 103 since the content is meant to be processed by an XML aware 104 application. The subtype defines the XML security mechanism, XML 105 Digital Signature or XML Encryption. The Multipart/Signed type also 106 requires definition of an micalg parameter, defined in the following 107 section on signature parameters (Section 3.2). Definition of the 108 parts is defined in the appropriate sections. 110 A general concern with mail is the ability of content to pass through 111 a variety of mail gateways, including mail systems which are only 112 capable of processing 7-bit UTF8. Content to be signed must be 113 exactly the same when received as when sent for signature 114 verification to succeed. Some gateways may convert data to enable 115 delivery, such as automatically converting to Quoted-Printable or 116 Base64 encoding. This will not allow signatures to be validated. 117 For this reason all data signed according to this protocol MUST be 118 constrained to 7 bits (8-bit data should be encoded using either 119 Quoted-Printable or Base64). XML content should also be 120 canonicalized, as discussed in the signature section (Section 3). 122 As discussed in the PGP RFC [6], applications using this standard 123 should follow MIME's suggestion that you "be conservative in what you 124 generate, and liberal in what you accept." In this particular case it 125 means it would be wise for an implementation to accept messages with 126 any content-transfer encoding, but restrict generation to the 7-bit 127 format required by this memo. This will allow future compatibility 128 in the event the Internet SMTP framework becomes 8-bit friendly. 130 It's generally a good idea to encode lines that begin with From= 131 because some mail transport agents will insert a greater-than (>) 132 sign, thus invalidating the signature. Also, in some cases it might 133 be desirable to encode any trailing whitespace that occurs on lines 134 in order to ensure that the message signature is not invalidated when 135 passing a gateway that modifies such whitespace (like BITNET). [6] 137 3. XML Digital Signatures with Multipart/Signed 139 3.1 Multipart/Signed MIME Parts 141 According to RFC 1847, Multipart/Signed content consists of exactly 142 two parts, the content part and the signature part. The first part 143 may be any type of content, encoded in MIME canonical format (e.g. 144 base64 encoded), and must include MIME headers defining the content 145 type. 147 The second part is a signature over the entire first part, including 148 the MIME headers. The second part must be labeled with the content 149 type of "application/signature+xml". 151 This signature must be an XML Digital Signature and MUST include one 152 reference to the first part. This reference does not require a URI, 153 but if a URI is present it may either be a CID or a full URL. If it 154 is a CID the first part must have a Content-ID header with a matching 155 value. If it is a URL, this URL must resolve to the same URL 156 specified in a Content-Location header in the first part. This is 157 discussed in detail in the SOAP with Attachments W3C Note [7]. 159 3.2 Parameters 161 As defined in RFC 1847, Multipart/Signed requires three parameters: 162 boundary, protocol and micalg. XML Signatures require support for a 163 fourth, optional parameter, "transform". 165 3.2.1 Boundary Parameter 167 Boundary is used to separate the parts, as defined in RFC 1847. 169 3.2.2 Protocol Parameter 171 The Multipart security protocol parameter will be defined as 172 "application/signature+xml" for XML Signatures. This parameter 173 specifies that the XML Digital Signature recommendation rules should 174 be followed in processing the XML Signature part, as well as the 175 Multipart security signature processing rules (Section 3.3) 176 discussed below. 178 3.2.3 Micalg Parameter 180 The Multipart Security RFC requires definition of the micalg 181 parameter for Multipart/Signed types. This allows one-pass signature 182 verification, since the parameter is used to specify the hash 183 algorithm and allows the content part to be hashed before the 184 signature part is processed. 186 This is compatible with the XML Digital Signature recommendation, 187 which requires a hash of the document to be generated to verify a 188 document reference. The XML digital signature recommendation 189 requires support for the SHA-1 hash, an algorithm currently supported 190 by common mail programs, which represent it as the "SHA1" value for 191 the micalg parameter. 193 We propose in this draft that XML identifiers (URIs) be REQUIRED as 194 micalg values for XML security types, allowing digest functions to 195 be specified using the URIs defined in the XML Digital Signature 196 recommendation. SHA-1 MUST be specified as 197 "http://www.w3.org/2000/09/xmldsig#sha1", for example. Note that the 198 digest algorithm is also specified inside the XML Signature itself, 199 but must be provided in micalg to support one-pass processing of 200 content before encountering the Signature element. 202 3.2.4 Transform Parameters 204 Enabling one-pass processing makes it important to allow signature 205 transforms to be defined in a MIME header, allowing one-pass 206 processing whenever possible, depending on the transforms. Examples 207 include canonicalization or an XPath transform allowing specific XML 208 content to be signed. If the signature requires transforms but they 209 are not specified in the header, calculating the digest before 210 processing the signature is incorrect. 212 The transform parameter is optional, but required if any transforms 213 are needed to create an XML signature reference. If transforms were 214 applied they must be specified in transform parameters, one per 215 parameter. These are processed in the order encountered. After the 216 transforms are applied, the hash is calculated. Each transform is 217 specified by the transform URI, and optionally one or more transform 218 parameters. An XPath transform, for example, will consist of the 219 XPath transform URI, a namespace context and then an expression 220 value, all separated by commas. Not all transforms or transform 221 combinations will allow one-pass processing. 223 In the following example, the element and its content is 224 signed (line breaks added for readability): 226 Content-Type: Multipart/Signed; 227 protocol="application/signature+xml"; 228 boundary="Signed Boundary"; 229 micalg="http://www.w3.org/2000/09/xmldsig#sha1"; 230 transform="http://www.w3.org/TR/1999/REC-xpath-19991116", 231 "http://spam.com/foo","//reason"; 232 transform="http://www.w3.org/TR/2001/REC-xml-c14n-20010315" 234 --Signed Boundary 235 Content-Type: text/xml; 236 Location: http://test.zolera.com/transformdoc.xml 238 239 Smith 240 returned 241 242 --Signed Boundary 243 Content-Type: application/signature+xml 245 246 248 ]> 249 250 251 253 254 255 256 257 //tns:reason 258 259 260 261 262 PxcEwz8QDxAQVqfGyJy69ql7lCE=o 263 264 265 nVwiEUEEJSv0txxkj/XrMDCVkx9ajF8Jk4Kglpg6/54dvd5wOMbstw0+ 266 TYx/lOD5S6CImb3J2hrdkCwAYYyL1A== 267 269 270 --Signed Boundary 272 Any XPath expression is defined to refer to the XML content of the 273 MIME body. This is the first part content, not including the MIME 274 headers. Use of XPath is only meaningful in this context if the body 275 content type is an XML type. It is required that any content 276 transform be expressed both as a transform parameter in the MIME 277 header as well as a transform in the XML Signature reference. 279 3.3 XML Signature Processing Rules 281 When the XML digital signature is generated: 283 1. The data to be signed must first be converted to its type/subtype 284 specific canonical form. For text/plain, this means conversion 285 to an appropriate character set and conversion of line endings to 286 the canonical sequence. XML content MUST be UTF8, if it 287 is not, Canonical XML version 1.0 MUST be used to ensure it is 288 UTF8. Binary data is not canonicalized. 290 2. An appropriate Content-Transfer-Encoding is then applied. Each 291 line of the encoded data MUST end with the canonical 292 sequence. This is base64 encoding for binary data. XML data 293 must have line endings normalized to (not the default of 294 canonicalization). 296 3. MIME content headers are then added to the body, each ending with 297 the canonical sequence. If a signature reference URI is 298 used, the content must have either a Content-ID or Content- 299 Location header added. 301 4. Before creating a signature over XML content, that content must 302 be canonicalized using Canonical XML version 1.0. This is 303 necessary to ensure that an XML signature will verify despite 304 different XML processor variants. Even if the XML was 305 canonicalized in the first step, it must have its line endings 306 canonicalized in this step. 308 5. A signature may either sign the entire MIME content part (headers 309 and content) or only a section of XML content. If the entire 310 MIME part is signed, the XML signature is created over that part 311 producing an XML Digital Signature element. This is the default. 312 The processing rules of the XML Digital Signature recommendation 313 must be followed. 315 6. If only a portion of XML (or only the entire XML content) is 316 signed, this must be specified using an XPath expression applied 317 to the entire XML content of the first MIME part (but not 318 including the headers). This expression MUST be included as a 319 reference transform and included in a transform header parameter. 320 The signature is created over the specified part following the 321 processing rules of the XML Digital Signature recommendation. 323 7. By default the result signature XML is placed in the second 324 signature MIME part, with the original content in the first part. 325 No URI is required for the content reference, but if a URI is 326 used it must be either a CID refering to the Content-ID header in 327 the first part, or a URL which resolves to the URL stated in a 328 the Content-Location header in the first part. 330 8. Alternatively, for a signature over XML or a portion of XML, the 331 signature may be included in the XML. In this case the second 332 signature MIME part will be empty. This requires the signature 333 to include the appropriate enveloped signature transform which 334 MUST also be included as a transform MIME parameter. 336 3.4 XML Signature Example 338 This is an example of a detached signature over the first part. 340 From: Frederick Hirsch 341 To: Frederick Hirsch 342 Mime-Version: 1.0 343 Content-Type: Multipart/Signed; 344 boundary=bar; 345 micalg="http://www.w3.org/2000/09/xmldsig#sha1"; 346 protocol="application/signature+xml"; 347 transform="http://www.w3.org/TR/2001/REC-xml-c14n-20010315" 348 --bar 349 Content-Type: text/xml; 350 Location: http://test.zolera.com/testdoc.xml 352 353 Something 354 Second item 355 356 --bar 357 Content-Type: application/signature+xml 359 360 362 ]> 363 364 365 367 368 369 370 372 373 374 3wCiU/BeKdVr6EZCsx7QtK6sPus= 375 376 377 BDx/XRkeg6a37wZNbqbCzF/bQE8GQ36Q35T4b9kbE6uf42QVhe9BOactW68T 378 532p6vYAI0ZuAUOLot8TrdhWtg== 379 380 user@zolera.com 381 382 383 --bar 385 4. XML Encryption with Multipart/Encrypted 387 4.1 Multipart/Encrypted MIME Parts 389 According to RFC 1847, Multipart/Encrypted content consists of 390 exactly two parts, a control part and the encrypted content part. 391 The control part must be the same type as the protocol parameter, in 392 this case "application/xml-encrypted". RFC 1847 requires the second 393 part to be labelled "application/octet-stream". 395 For XML encryption the control part MUST contain the XML Encryption 396 content, XML containing one or more EncryptedData elements. The 397 encrypted content part of the MIME message may be empty if the 398 ciphertext is contained in the XML EncryptedData elements. This is a 399 common case, with the CipherValue element containing the data. 401 If the cipher data is not included in the XML EncryptedData it may be 402 placed in the second encrypted data MIME part, base64 encoded. The 403 EncryptedData CipherReference element will refer to it using a CID or 404 a URL. If a CID is used, the encrypted content MIME part must have a 405 corresponding Content-ID header. If a URL is used, the encrypted 406 content MIME part must have a corresponding Content-Location header. 408 It is possible for the cipher data to be stored in the network, in 409 which case the CipherReference URL specifies this location and the 410 cipher data is in neither Mime part. 412 4.2 Parameters 414 As defined in RFC 1847, Multipart/Encrypted requires two parameters: 415 boundary and protocol. Boundary is used to separate the parts, as 416 defined in RFC 1847. 418 4.2.1 Protocol Parameter 420 The protocol parameter is required to be "application/xml-encrypted" 421 for XML encryption. 423 4.3 XML Encryption Processing Rules 425 When the XML encrypted content is generated: 427 1. Before encryption, the data should be written in MIME canonical 428 format (body and headers). 430 2. If the entire content is to be encrypted (both headers and 431 content), the XML Encryption processing rules should be followed, 432 producing an XML EncryptedData element. This is placed in the 433 first MIME encryption control part. If the cipher data is 434 included in the XML EncryptedData element the second MIME part 435 for encrypted data will be empty. Alternatively, the cipher data 436 may be placed in the second MIME part, with a reference from the 437 first part. This reference may be a CID which must correspond to 438 a Content-ID header in the second part, or a URL which resolves 439 to match a Content-Location header in the second part. 441 3. If a portion of XML is encrypted, it is replaced with an 442 Encrypted Data element, and the entire content is placed in the 443 first MIME control section. The cipherdata may be embedded in 444 the XML and the second MIME part will be empty, or may refer to 445 the cipher data in the second part. 447 Using a reference to cipher data in the second MIME part has the 448 advantage that the XML may be parsed without the efficiency and size 449 limitations of a large amount of cipherdata. 451 4.4 XML Encryption Example 453 An example of a encrypting the content in the first part and placing 454 the ciphervalue in the second part is: 456 From: Frederick Hirsch 457 To: Frederick Hirsch 458 Mime-Version: 1.0 459 Content-Type: multipart/encrypted; 460 boundary=foo; 461 protocol="application/xml-encrypted" 462 --foo 463 Content-Type: application/xml-encrypted 465 466 468 ]> 470 472 473 474 John Smith 475 476 477 478 479 480 --foo 481 Content-Type: application/octet-stream 482 Content-ID: 33 484 IWijxQjUrcXBYoCei4QxjWo9Kg8D3p9tlWoT4t0/gyTE96639In0FZFY2/rvP+/b 485 MJ01EArmKZsR5VW3rwoPxw= 486 --foo-- 488 4.5 Security Considerations 490 This entire document is about security. Note that MD5 is not a 491 recommended digest algorithm, given known security weaknesses. 493 Sometimes it is desirable to both digitally sign and then encrypt a 494 message to be sent. XML digital signature and encryption are 495 designed to be combined. Signing and then encrypting may result as a 496 Multipart/Encrypted object as defined above. Signing an encrypted 497 object (not necessarily meaningful if the signer did not see what 498 they signed) would involve the data object containing the encrypted 499 multipart content. 501 See the recommendations for a discussion of security considerations 502 associated with XML Digital Signatures [4] and XML Encryption [5]. 504 References 506 [1] Galvin, J., Murphy, G., Crocker, S. and N. Freed, "Security 507 Multiparts for MIME: Multipart/Signed and Multipart/Encrypted", 508 RFC 1847, October 1995. 510 [2] Galvin, J., Murphy, G., Crocker, S. and N. Freed, "MIME Object 511 Security Services", RFC 1848, October 1995. 513 [3] Boyer, J., "Canonical XML, Version 1.0, W3C Recommendation", 514 RFC 3076, March 2001, . 516 [4] Eastlake, D., Reagle, J. and D. Solo, "XML-Signature Syntax and 517 Processing", RFC 3075, DRAFT, Obsoletes RFC 3075 , February 518 2002, . 520 [5] Eastlake, D., Reagle, J., Imamura, T., Dillaway, B., Schaad, J. 521 and E. Simon, "XML-Encryption Syntax and Processing, WG DRAFT", 522 W3C Working Draft , June 2001, . 525 [6] Elkins, M., "MIME Security with Pretty Good Privacy (PGP)", RFC 526 2015, October 1996. 528 [7] Barton, J., Thatte, S. and H. Frystyk, "SOAP Messages with 529 Attachments", W3C Note , December 2000, 530 . 532 [8] Murata, M., St.Laurent, S. and D. Kohn, "XML Media Types", RFC 533 3023, Obsoletes 2376, Updates 2048, January 2001. 535 [9] Clark, J. and S. DeRose, "XML Path Language (XPath), Version 536 1.0", W3C Recommendation , November 1999, 537 . 539 [10] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 540 Informational , June 1999. 542 Author's Address 544 Frederick J. Hirsch 545 Zolera Systems, Inc. 546 600 W. Cummings Park 547 Suite 2000 548 Woburn, MA 01801 549 US 551 Phone: +1 781 759 1122 x15 552 EMail: fjh@alum.mit.edu 553 URI: http://www.zolera.com/ 555 Appendix A. Acknowledgements 557 This draft was written using XML [10]. The author appreciates the 558 review by Rich Salz. 560 Full Copyright Statement 562 Copyright (C) The Internet Society (2001). All Rights Reserved. 564 This document and translations of it may be copied and furnished to 565 others, and derivative works that comment on or otherwise explain it 566 or assist in its implementation may be prepared, copied, published 567 and distributed, in whole or in part, without restriction of any 568 kind, provided that the above copyright notice and this paragraph are 569 included on all such copies and derivative works. However, this 570 document itself may not be modified in any way, such as by removing 571 the copyright notice or references to the Internet Society or other 572 Internet organizations, except as needed for the purpose of 573 developing Internet standards in which case the procedures for 574 copyrights defined in the Internet Standards process must be 575 followed, or as required to translate it into languages other than 576 English. 578 The limited permissions granted above are perpetual and will not be 579 revoked by the Internet Society or its successors or assigns. 581 This document and the information contained herein is provided on an 582 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 583 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 584 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 585 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 586 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 588 Acknowledgement 590 Funding for the RFC Editor function is currently provided by the 591 Internet Society.