idnits 2.17.1 draft-ietf-pkix-cmp-transport-protocols-05.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: ---------------------------------------------------------------------------- == 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 draft header indicates that this document updates RFC2510, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). (Using the creation date from RFC2510, updated by this document, for RFC5378 checks: 1996-06-14) -- 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 (February 9, 2004) is 7379 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: 'RFC2510' is mentioned on line 216, but not defined ** Obsolete undefined reference: RFC 2510 (Obsoleted by RFC 4210) ** Obsolete normative reference: RFC 2510 (ref. 'CMP') (Obsoleted by RFC 4210) ** Obsolete normative reference: RFC 2482 (Obsoleted by RFC 6082) ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 3066 (Obsoleted by RFC 4646, RFC 4647) -- Obsolete informational reference (is this intentional?): RFC 821 (Obsoleted by RFC 2821) Summary: 7 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Kapoor 3 Internet-Draft R. Tschalar 4 Updates: 2510 (if approved) Certicom 5 Expires: August 9, 2004 T. Kause 6 SSH 7 February 9, 2004 9 Internet X.509 Public Key Infrastructure -- Transport Protocols for 10 CMP 11 draft-ietf-pkix-cmp-transport-protocols-05.txt 13 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 19 Task 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 http:// 28 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 This Internet-Draft will expire on August 9, 2004. 35 Copyright Notice 37 Copyright (C) The Internet Society (2004). All Rights Reserved. 39 Abstract 41 This document describes how to layer Certificate Management Protocols 42 over various transport protocols. 44 Table of Contents 46 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3 47 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 4 48 3. TCP-Based Management Protocol . . . . . . . . . . . . . . 5 49 3.1 General Form . . . . . . . . . . . . . . . . . . . . . . . 5 50 3.2 Version Negotiation . . . . . . . . . . . . . . . . . . . 6 51 3.3 TCP-message Version 10 . . . . . . . . . . . . . . . . . . 6 52 3.4 Detecting and Interoperating with RFC-2510 Conformant 53 Implementations . . . . . . . . . . . . . . . . . . . . . 7 54 3.5 Message Types . . . . . . . . . . . . . . . . . . . . . . 7 55 3.5.1 pkiReq . . . . . . . . . . . . . . . . . . . . . . . . . . 8 56 3.5.2 pkiRep . . . . . . . . . . . . . . . . . . . . . . . . . . 9 57 3.5.3 pollReq . . . . . . . . . . . . . . . . . . . . . . . . . 9 58 3.5.4 pollRep . . . . . . . . . . . . . . . . . . . . . . . . . 10 59 3.5.5 finRep . . . . . . . . . . . . . . . . . . . . . . . . . . 10 60 3.5.6 errorMsgRep . . . . . . . . . . . . . . . . . . . . . . . 10 61 3.5.7 VersionNotSupported errorMsgRep . . . . . . . . . . . . . 11 62 3.5.8 GeneralClientError errorMsgRep . . . . . . . . . . . . . . 11 63 3.5.9 InvalidMessageType errorMsgRep . . . . . . . . . . . . . . 12 64 3.5.10 InvalidPollID errorMsgRep . . . . . . . . . . . . . . . . 12 65 3.5.11 GeneralServerError errorMsgRep . . . . . . . . . . . . . . 12 66 4. HTTP-Based Management Protocol . . . . . . . . . . . . . . 13 67 5. File based protocol . . . . . . . . . . . . . . . . . . . 14 68 6. Mail based protocol . . . . . . . . . . . . . . . . . . . 15 69 7. Security Considerations . . . . . . . . . . . . . . . . . 16 70 Normative References . . . . . . . . . . . . . . . . . . . 17 71 Informative References . . . . . . . . . . . . . . . . . . 18 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 18 73 A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 19 74 B. Registration of MIME Type for E-Mail or HTTP Use . . . . . 20 75 Intellectual Property and Copyright Statements . . . . . . 22 77 1. Introduction 79 Well defined transport mechanisms are required for Certificate 80 Management Protocol [CMP] in order to allow end entities, RAs and CAs 81 to pass PKI messages between them. 83 2. Requirements 85 The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", 86 "RECOMMENDED", "MAY", and "OPTIONAL" in this document (in uppercase, 87 as shown) are to be interpreted as described in [RFC2119]. 89 3. TCP-Based Management Protocol 91 While this section is called TCP-Based and the messages are called 92 TCP-message's, the same protocol can be used over any reliable, 93 connection oriented transport protocol (e.g. SNA, DECnet, etc.). This 94 protocol is suitable for cases where an end entity (or an RA) 95 initiates a transaction and can poll to pick up the results. 97 The client sends a TCP-message to the server, and the server responds 98 with another TCP-message. Note that a response MUST be sent for every 99 request, even if the encapsulated CMP message in the request does not 100 have a corresponding response. 102 The protocol basically assumes a listener process on an RA or CA 103 which can accept TCP-messages on a well-defined port (default port 104 number is 829). Typically a client initiates connection to the server 105 and submits a PKI message. The server replies with a PKI message or 106 with a reference number to be used later when polling for the actual 107 PKI message response. 109 If a polling-reference was supplied then the client will send a 110 polling request using this polling-reference after waiting for at 111 least the specified time. The server may again reply with a 112 polling-reference or with the actual PKI message response. 114 When the final PKI response message has been picked up by the client 115 then no new polling reference is supplied. 117 If a transaction is initiated by a PKI entity (RA or CA) then an end 118 entity must either supply a listener process or be supplied with a 119 polling reference (see below) in order to allow it to pick up the PKI 120 message from the PKI management component. 122 3.1 General Form 124 A TCP-message consists of: 126 length (32-bits) 128 version (8-bits) 130 flags (variable length) 132 message-type (8-bits) 134 value (defined below) 136 The length field contains the number of octets of the remainder of 137 the TCP-message (i.e., number of octets of plus 138 plus 2). All bit values in this protocol are specified 139 to be in network byte order 141 The version field indicates the version of the TCP-message. It MUST 142 be incremented for each specification which changes the flags field 143 in a way that is not fully backwards compatible with the previous 144 version (e.g. when the length of the flags field is changed). 146 The flags field is for transporting TCP-message specific data. The 147 length of this field is version dependent and is fixed for a given 148 version. 150 The message-type field is used to indicate the type of TCP-message. 152 The value field contains message-type dependent data. 154 3.2 Version Negotiation 156 If a client knows the protocol version(s) supported by the server 157 (e.g. from a previous TCP-message exchange or via some out-of-band 158 means) then it SHOULD send a TCP-message with the highest version 159 supported both by it and the server. If a client does not know what 160 version(s) the server supports then it SHOULD send a TCP-message 161 using the highest version it supports. 163 If a server receives a TCP-message version that it supports, then it 164 MUST reply with a TCP-message of the same version. If the version 165 received is higher than what the server supports, it MUST send back a 166 VersionNotSupported errorMsgRep (defined below) containing the 167 highest version it supports. 169 3.3 TCP-message Version 10 171 The TCP-message version will be 10 for this document. The number has 172 deliberately been chosen to prevent [RFC2510] compliant applications 173 from treating it as a valid message type. Applications receiving a 174 version less than 10 SHOULD interpret the message as being an 175 [RFC2510] style message. 177 The length of the flags field for this version is 1 octet. The LSB is 178 used to indicate a connection close; all other bits in the flags 179 octet MUST be ignored by receivers, and MUST be set to zero by 180 senders. 182 By default connections are kept open after the receipt of a response. 183 Either party (client or server) MAY set the connection close bit at 184 any time. If the connection close bit is set on a request, then the 185 server MUST set the bit in the response and close the connection 186 after sending the response. If the bit is set on a response from the 187 server, the client MUST NOT send any further requests on that 188 connection. Applications MAY decide to close an idle connection (one 189 on which no response is outstanding) after some time-out. Because of 190 the problem where a client sends a request and the server closes the 191 connection while the request is still in flight, clients SHOULD 192 automatically retry a request for which no part of the response could 193 be read due to a connection close or reset. 195 If the connection is kept open, it MUST only be used for subsequent 196 request/response transactions started by the client - the server MUST 197 NOT use it to send requests to the client. Different transactions may 198 be freely interwoven on the same connection. E.g. a CR/CP need not 199 immediately be followed by the Confirm, but may be followed by any 200 other request from a different transaction. 202 3.4 Detecting and Interoperating with RFC-2510 Conformant 203 Implementations 205 Servers wishing to interoperate with clients conforming to [RFC2510] 206 can do so by treating any received message with a version less than 207 10 as an [RFC2510] message and responding in that format. Servers not 208 wishing to support [RFC2510] messages MUST respond with a [RFC2510] 209 errorMsgRep. 211 Clients wishing to interoperate with [RFC2510] compliant servers 212 SHOULD treat a response with a version less than 10 as an [RFC2510] 213 style message. If this message is an errorMsgRep (message-type 06) 214 then the client MAY automatically retry the request using the 215 [RFC2510] format; if the message is not an errorMsgRep or the 216 implementation does not wish to support [RFC2510] then it MUST abort 217 the corresponding CMP transaction. 219 3.5 Message Types 221 message-types 0-127 are reserved and will be issued under IANA 222 auspices. message-types 128-255 are reserved for application use. 224 The message-type's currently defined are: 226 Message name Message-type 228 pkiReq '00'H 230 pollRep '01'H 232 pollReq '02'H 233 finRep '03'H 235 pkiRep '05'H 237 errorMsgRep '06'H 239 If server receives an unknown message-type then it MUST reply with an 240 InvalidMessageType errorMsgRep. If a client receives an unknown 241 message-type then it MUST abort the CMP transaction. 243 The different TCP-messages are discussed in the following sections: 245 3.5.1 pkiReq 247 The pkiReq is to be used to carry a PKIMessage from the client to the 248 server. The portion of this TCP-message will contain: 249 DER-encoded PKIMessage. 251 The type of PKIMessages that can be carried by this TCP-message are: 253 CRL Announcement 255 Certificate Confirmation 257 Poll Request 259 Subscription Request 261 CA Key Update Announcement 263 Certificate Announcement 265 Certification Request 267 Cross-Certification Request 269 Error Message 271 General Message 273 Initialization Request 275 Key Recovery Request 277 Key Update Request 279 Nested Message 280 PKCS-10 Request 282 POP Response 284 Revocation Request 286 3.5.2 pkiRep 288 This TCP-message is to be used to send back the response to the 289 request. The portion of the pkiRep will contain: DER encoded 290 PKI message 292 The type of PKIMessages that can be carried by this TCP-message are: 294 Confirmation 296 Poll Response 298 Subscription Response 300 Certification Response 302 Error Message 304 General Response 306 Initialization Response 308 Key Recovery Response 310 Key Update Response 312 POP Challenge 314 Revocation Response 316 3.5.3 pollReq 318 The pollReq will be the used by the client to check the status of a 319 pending TCP-message. The portion of the pollReq will 320 contain: 322 polling-reference (32 bits) 324 The MUST be the one returned via the pollRep 325 TCP-message. 327 3.5.4 pollRep 329 The pollRep will be the response sent by the server to the client 330 when there are no TCP-message response ready. The portion of 331 the pollRep will contain: 333 polling-reference (32 bits) 335 time-to-check-back (32 bits) 337 The is a unique 32-bit number sent by the server. 338 The is the time in seconds indicating the 339 minimum interval after which the client SHOULD check the status 340 again. The duration for which the server keeps the 341 unique is left to the implementation. 343 3.5.5 finRep 345 finRep is sent by the server whenever no other response applies (such 346 as after receiving a CMP pkiConf), and usually indicates the end of 347 the CMP transaction. The portion of the finRep SHALL contain: 349 '00'H (8 bits) 351 3.5.6 errorMsgRep 353 This TCP-message is sent when a TCP-message level protocol error is 354 detected. Please note that PKIError messages MUST NOT be sent using 355 this. Examples of TCP-message level errors are: 357 1. Invalid protocol version 359 2. Invalid TCP message-type 361 3. Invalid polling reference number 363 The %lt;value> field of the TCP-message SHALL contain: 365 error-type (16-bits) 367 data-length (16-bits) 369 data ( octets) 371 UTF8 String (SHOULD include an [RFC3066] language tag, as 372 described in [RFC2482]) 374 The is of the form MMNN where M and N are hex digits 375 (0-F) and MM represents the major category and NN the minor. The 376 major categories defined by this specification are: 378 '01'H TCP-message version negotiation 380 '02'H client errors 382 '03'H server errors 384 The major categories '80'H-'FF'H are reserved for application use. 386 The and are additional information about the 387 error to be used by programs for further processing and recovery. 388 contains the length of the field in number of 389 octets. Error messages not needing additional information to be 390 conveyed MUST set the to 0. 392 The UTF8 text string is for user readable error messages. Note that 393 it does not contain a terminating null character at the end. 395 3.5.7 VersionNotSupported errorMsgRep 397 The VersionNotSupported errorMsgRep is defined as follows: 399 error-type: '0101'H 401 data-length: 1 403 data: 405 UTF8-text String: implementation defined 407 where is the highest version the server supports. 409 3.5.8 GeneralClientError errorMsgRep 411 The GeneralClientError errorMsgRep is defined as follows: 413 error-type: '0200'H 415 data-length: 0 417 data: 419 UTF8-text String: implementation defined 421 3.5.9 InvalidMessageType errorMsgRep 423 The InvalidMessageType errorMsgRep is defined as follows: 425 error-type: '0201'H 427 data-length: 1 429 data: 431 UTF8-text String: implementation defined 433 where is the message-type received by the server. 435 3.5.10 InvalidPollID errorMsgRep 437 The InvalidPollID errorMsgRep is defined as follows: 439 error-type: '0202'H 441 data-length: 4 443 data: 445 UTF8-text String: implementation defined 447 where is the polling-reference received by the 448 server. 450 3.5.11 GeneralServerError errorMsgRep 452 The GeneralServerError errorMsgRep is defined as follows: 454 error-type: '0300'H 456 data-length: 0 458 data: 460 UTF8-text String: implementation defined 462 4. HTTP-Based Management Protocol 464 A client creates a TCP-message, as specified in section 2.0 XXX . The 465 message is then sent as the entity-body of an HTTP POST request as 466 specified in [RFC2616]. If the HTTP request is successful then the 467 server returns a similar message in the body of the response. The 468 response status code in this case MUST be 200; other 2xx codes MUST 469 NOT be used. The content type of the request and response MUST be 470 "application/pkixcmp". Applications MAY wish to also recognized and 471 use the "application/pkixcmp-poll" MIME type (specified in earlier 472 versions of this document) in order to support backward compatibility 473 wherever applicable. Content codings may be applied. 475 Note that a server may return any 1xx, 3xx, 4xx, or 5xx code if the 476 HTTP request needs further handling or is otherwise not acceptable. 478 Because in general CMP messages are not cacheable, requests and 479 responses should include a "Cache-Control: no-cache" (and, if either 480 side uses HTTP/1.0, a "Pragma: no-cache") to prevent the client from 481 getting cached responses. This is especially important for polling 482 requests and responses. 484 Connection management SHOULD be based on the HTTP provided mechanisms 485 (Connection and Proxy-Connection header fields) and not on the 486 connection flag carried in the TCP-message. 488 5. File based protocol 490 A file containing a PKI message MUST contain only the DER encoding of 491 one PKI message, i.e., there MUST be no extraneous header or trailer 492 information in the file. 494 Such files can be used to transport PKI messages using, e.g., FTP. 496 6. Mail based protocol 498 This subsection specifies a means for conveying ASN.1-encoded 499 messages for the protocol exchanges via Internet mail ([RFC821]. A 500 simple MIME object is specified as follows. 502 Content-Type: application/pkixcmp 503 Content-Transfer-Encoding: base64 505 <> 507 This MIME object can be sent and received using common MIME 508 processing engines and provides a simple Internet mail transport for 509 PKIX-CMP messages. Implementations MAY wish to also recognize and 510 use the "application/x-pkixcmp" MIME type (specified in earlier 511 versions of this document) in order to support backward compatibility 512 wherever applicable. 514 7. Security Considerations 516 Three aspects need to be considered by server side implementors: 518 1. There is no security at the TCP and HTTP protocol level (unless 519 tunneled via SSL/TLS) and thus TCP-message should not be used to 520 change state of the transaction. Change of state should be done 521 on the signed PKIMessage being carried within the TCP-message. 523 2. If the server is going to be sending messages with sensitive 524 information (not meant for public consumption) in the clear, it 525 is RECOMMENDED that the server send back the message directly and 526 not use the pollRep. 528 3. The polling request/response mechanism can be used for all kinds 529 of denial of service attacks. It is RECOMMENDED that the server 530 not change the polling-reference between polling requests. 532 Normative References 534 [CMP] Adams, C., Farrell, S., Kause, T. and T. Mononen, 535 "Internet X.509 Public Key Infrastructure -- Certificate 536 Management Protocol (CMP)", RFC 2510bis, January 0000. 538 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 539 Requirement Levels", BCP 14, RFC 2119, March 1997. 541 [RFC2482] Whistler, K. and G. Adams, "Language Tagging in Unicode 542 Plain Text", RFC 2482, January 1999. 544 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 545 Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext 546 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 548 [RFC3066] Alvestrand, H., "Tags for the Identification of 549 Languages", BCP 47, RFC 3066, January 2001. 551 Informative References 553 [RFC821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 554 821, August 1982. 556 Authors' Addresses 558 Amit Kapoor 559 Certicom 560 25801 Industrial Blvd 561 Hayward, CA 562 US 564 EMail: amit@trustpoint.com 566 Ronald Tschalar 567 Certicom 568 25801 Industrial Blvd 569 Hayward, CA 570 US 572 EMail: ronald@trustpoint.com 574 Tomi Kause 575 SSH Communications Security Corp. 576 Fredrikinkatu 42 577 Helsinki 00100 578 Finland 580 EMail: toka@ssh.com 582 Appendix A. Acknowledgments 584 The authors gratefully acknowledge the contributions of various 585 members of the IETF PKIX Working Group and the ICSA CA-talk mailing 586 list (a list solely devoted to discussing CMP interoperability 587 efforts). 589 Appendix B. Registration of MIME Type for E-Mail or HTTP Use 591 To: ietf-types@iana.org 592 Subject: Registration of MIME media type application/pkixcmp 594 MIME media type name: application 596 MIME subtype name: pkixcmp 598 Required parameters: - 600 Optional parameters: - 602 Encoding considerations: 604 Content may contain arbitrary octet values (the ASN.1 DER encoding 605 of a PKI message, as defined in the IETF PKIX Working Group 606 specifications). base64 encoding is required for MIME e-mail; no 607 encoding is necessary for HTTP. 609 Security considerations: 611 This MIME type may be used to transport Public-Key Infrastructure 612 (PKI) messages between PKI entities. These messages are defined by 613 the IETF PKIX Working Group and are used to establish and maintain 614 an Internet X.509 PKI. There is no requirement for specific 615 security mechanisms to be applied at this level if the PKI messages 616 themselves are protected as defined in the PKIX specifications. 618 Interoperability considerations: - 620 Published specification: this document 622 Applications which use this media type: Applications using 623 certificate management, operational, or ancillary protocols (as 624 defined by the IETF PKIX Working Group) to send PKI messages via 625 E-Mail or HTTP. 627 Additional information: 629 Magic number (s): - 630 File extension (s): ".PKI" 631 Macintosh File Type Code (s): - 633 Person and email address to contact for further information: 634 Tomi Kause, toka@ssh.com 635 Intended usage: COMMON 637 Author/Change controller: Tomi Kause 639 Intellectual Property Statement 641 The IETF takes no position regarding the validity or scope of any 642 intellectual property or other rights that might be claimed to 643 pertain to the implementation or use of the technology described in 644 this document or the extent to which any license under such rights 645 might or might not be available; neither does it represent that it 646 has made any effort to identify any such rights. Information on the 647 IETF's procedures with respect to rights in standards-track and 648 standards-related documentation can be found in BCP-11. Copies of 649 claims of rights made available for publication and any assurances of 650 licenses to be made available, or the result of an attempt made to 651 obtain a general license or permission for the use of such 652 proprietary rights by implementors or users of this specification can 653 be obtained from the IETF Secretariat. 655 The IETF invites any interested party to bring to its attention any 656 copyrights, patents or patent applications, or other proprietary 657 rights which may cover technology that may be required to practice 658 this standard. Please address the information to the IETF Executive 659 Director. 661 Full Copyright Statement 663 Copyright (C) The Internet Society (2004). All Rights Reserved. 665 This document and translations of it may be copied and furnished to 666 others, and derivative works that comment on or otherwise explain it 667 or assist in its implementation may be prepared, copied, published 668 and distributed, in whole or in part, without restriction of any 669 kind, provided that the above copyright notice and this paragraph are 670 included on all such copies and derivative works. However, this 671 document itself may not be modified in any way, such as by removing 672 the copyright notice or references to the Internet Society or other 673 Internet organizations, except as needed for the purpose of 674 developing Internet standards in which case the procedures for 675 copyrights defined in the Internet Standards process must be 676 followed, or as required to translate it into languages other than 677 English. 679 The limited permissions granted above are perpetual and will not be 680 revoked by the Internet Society or its successors or assignees. 682 This document and the information contained herein is provided on an 683 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 684 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 685 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 686 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 687 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 689 Acknowledgment 691 Funding for the RFC Editor function is currently provided by the 692 Internet Society.