Long-term Archive And Notary C. Wallace Services (LTANS) Orion Security Solutions Internet-Draft U. Pordesch Expires: January 18, 2006 Fraunhofer Gesellschaft R. Brandner InterComponentWare AG July 17, 2005 Long-Term Archive Service Requirements draft-ietf-ltans-reqs-04.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on January 18, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract There are many scenarios in which users must be able to prove the existence of data at a specific point in time and be able to demonstrate the integrity of data since that time, even when the duration from time of existence to time of demonstration spans a large period of time. Additionally, users must be able to verify Wallace, et al. Expires January 18, 2006 [Page 1] Internet-Draft Archive Requirements July 2005 signatures on digitally signed data many years after the generation of the signature. This document describes a class of long-term archive services to support such scenarios and the technical requirements for interacting with such services. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. General Principles . . . . . . . . . . . . . . . . . . . . . . 8 4. Technical Requirements . . . . . . . . . . . . . . . . . . . . 9 4.1 Enable submission, retrieval and deletion of archived data objects . . . . . . . . . . . . . . . . . . . . . . . 9 4.1.1 Functional Requirements . . . . . . . . . . . . . . . 9 4.1.2 Rationale . . . . . . . . . . . . . . . . . . . . . . 9 4.2 Enable management of archived data objects . . . . . . . . 10 4.2.1 Functional Requirements . . . . . . . . . . . . . . . 10 4.2.2 Rationale . . . . . . . . . . . . . . . . . . . . . . 10 4.3 Provide evidence records that support demonstration of data integrity . . . . . . . . . . . . . . . . . . . . . . 11 4.3.1 Functional Requirements . . . . . . . . . . . . . . . 11 4.3.2 Rationale . . . . . . . . . . . . . . . . . . . . . . 11 4.4 Operate per a long-term archive policy . . . . . . . . . . 11 4.4.1 Functional Requirements . . . . . . . . . . . . . . . 12 4.4.2 Rationale . . . . . . . . . . . . . . . . . . . . . . 12 4.5 Support data confidentiality . . . . . . . . . . . . . . . 13 4.5.1 Functional Requirements . . . . . . . . . . . . . . . 13 4.5.2 Rationale . . . . . . . . . . . . . . . . . . . . . . 13 4.6 Provide means to transfer data and evidence from one service to another . . . . . . . . . . . . . . . . . . . . 13 4.6.1 Functional Requirements . . . . . . . . . . . . . . . 13 4.6.2 Rationale . . . . . . . . . . . . . . . . . . . . . . 13 4.7 Support operations on groups of data objects . . . . . . . 14 4.7.1 Functional Requirements . . . . . . . . . . . . . . . 14 4.7.2 Rationale . . . . . . . . . . . . . . . . . . . . . . 14 5. Operational Considerations . . . . . . . . . . . . . . . . . . 15 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 8.1 Normative References . . . . . . . . . . . . . . . . . . . 18 8.2 Informative References . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 18 A. Application scenarios . . . . . . . . . . . . . . . . . . . . 20 A.1 Archive service supporting long-term non-repudiation . . . 20 A.2 Pure long-term non-repudiation service . . . . . . . . . . 20 A.3 Long-term Archive Service as part of an internal network . . . . . . . . . . . . . . . . . . . . . . . . . 20 A.4 Long-term Archive External Service . . . . . . . . . . . . 20 Wallace, et al. Expires January 18, 2006 [Page 2] Internet-Draft Archive Requirements July 2005 Intellectual Property and Copyright Statements . . . . . . . . 21 Wallace, et al. Expires January 18, 2006 [Page 3] Internet-Draft Archive Requirements July 2005 1. Introduction Digital data durability is undermined by continual progress and change on a number of fronts. The useful lifetime of data may exceed the life span of formats and mechanisms used to store the data. The lifetime of digitally signed data may exceed the validity periods of public-key certificates used to verify signatures or the cryptanalysis period of the cryptographic algorithms used to generate the signatures. Technical and operational means are required to mitigate these issues. A solution must address issues such as storage media lifetime, disaster planning, advances in cryptanalysis or computational capabilities, changes in software technology and legal issues. A long-term archive service aids in the preservation of data over long periods of time through a regimen of technical and procedural mechanisms designed to support claims regarding a data object. For example, it might periodically perform activities to preserve data integrity and the non-reputability of data existence by a particular point in time as well as ensuring the availability of data. Examples of periodic activities include refreshing time-stamps or transferring data to a new storage medium. A long-term archive service may be used to provide evidence that supports validation of the existence of documents or assertions of agreements that were originally asserted with digital signatures. Validation may occur at times in the future well beyond the validity period of the private key originally used to generate the signature, or even the validity of the algorithms available for digital signatures, message digesting or data encryption. A long-term archive service may be located within an enterprise network, communicating with local storage mechanisms and other applications, or a long-term archive service may be implemented as an external service accessible via the Internet. A long-term archive service may use functionality, e.g. time stamping, provided by independent service providers. A primary goal of a long-term archive service is to support the credible assertion of a claim that is currently asserted, at points well into the future. A long-term archive service may support a range of applications, including: wills, land records, medical data, criminal case files, personnel files, contracts. A long-term archive service may be used by any type of entity, e.g. organizations, citizens, notaries. Examples of long-term archive service usage by submitters include: Wallace, et al. Expires January 18, 2006 [Page 4] Internet-Draft Archive Requirements July 2005 - A company stores contracts using a third party service - A hospital stores medical data using an internal service - An individual wants to generate evidence of data possession at a particular point in time, e.g. for intellectual property purposes or endorsement of a contract - A law enforcement officer wants to store criminal data such that integrity of the data can be demonstrated years later For each of the above examples, there is a corresponding example involving retrievers, e.g. a company retrieves a contract in the case of a dispute or a law enforcement officer prepares information for a criminal trial. This document addresses the technical requirements for a long-term archive service. The requirements for certification services will be covered by a separate draft. Wallace, et al. Expires January 18, 2006 [Page 5] Internet-Draft Archive Requirements July 2005 2. Terminology We define the following terms based on their usage in the archiving community, in order to provide a vocabulary for describing requirements and the standards around them. Arbitrator: Principal for whom the validity of archived data characteristics, e.g., origin, integrity or time of existence, must be demonstrated. Archivation period: The period during which an archived data object is preserved by a long-term archive service. Archived data object: Data unit to be preserved by a long-term archive service. Archive package: Collection of information including archived data objects and associated evidence record. Evidence: Information that may be used to demonstrate the validity an archived data object or related attestations. Evidence record: Collection of evidence compiled for one or more archived data objects. An evidence record may include acknowledgements from a long-term archive service, time-stamps and verification data, such as public-key certificates, revocation information, trust anchors, policy details and role information. Long-term archive policy: A named set of rules that define operational characteristics of a long-term archive service. Wallace, et al. Expires January 18, 2006 [Page 6] Internet-Draft Archive Requirements July 2005 Long-term archive service (LTA): A service that is responsible for preserving data for long periods. Modifier: Principal who modifies attributes associated with an archived data object and/or evidence record held by a long-term archive service. Originator: Principal who produces, and possibly signs, an archived data object. The Originator does not necessarily have any relationship with a long-term archive service or any awareness of an evidence record associated with the archived data object. Retriever: Principal who retrieves archived data objects and/or evidence records from a long-term archive service. Submitter: Principal who submits data objects for archiving. Time-stamp: An attestation generated by a Time Stamping Authority (TSA) that a data item existed at a certain time. For example, [RFC 3161] specifies a structure for signed time-stamp tokens as part of a protocol for communicating with a Time-Stamp Authority (TSA). Time-Stamp Authority (TSA): A trusted service that provides attestations of existence of data at particular points in time. For example, [RFC 3161] defines protocol elements for interacting with a TSA. Wallace, et al. Expires January 18, 2006 [Page 7] Internet-Draft Archive Requirements July 2005 3. General Principles A long-term archive service may accept any type of data for preservation. The data might be in any format, whether textual data, images, documents, applications, or compound packages of multiple components. The data may be digitally signed, time-stamped, encrypted, or not subject to any cryptographic processing. A long-term archive service may preserve archived data objects as opaque collections of bytes with the primary aim being demonstration of data integrity. A long-term archive service is not required to operate upon evidence related to the content of archived data objects. Content-focused operations, including data format migration or translation, may be performed by a other services, e.g., certification services. However, an LTA may incorporate support for such services. Different long-term archive services may establish policies and procedures for archiving data objects over different lengths of time. For example, an LTA may refuse to preserve archived data objects for periods longer than 30 years. Similarly, LTAs may establish policies that limit the types of data that will be accepted for deposit by a particular LTA. A long-term archive service provides a evidence that may be used to demonstrate the existence of archived data object at a given time and the integrity of the archived data object since that time. Additionally, the evidence identifies the LTA(s) that have participated in the preservation of the archived data object. If the archived data object itself contains digitally signed data, authentication of the signer is also possible. Wallace, et al. Expires January 18, 2006 [Page 8] Internet-Draft Archive Requirements July 2005 4. Technical Requirements This section describes the requirements for the protocol for accessing a long-term archive system and for the data formats associated with data preservation. 4.1 Enable submission, retrieval and deletion of archived data objects 4.1.1 Functional Requirements A long-term archive service must permit clients to request the following basic operations: - submit data objects for archive - retrieve archived data objects, - delete archived data objects, Following submission, the service must provide a value that can be used to retrieve the archived data and/or associated evidence. For example, it may be possible to retrieve archive packages by using a hash value of an archived data object. Possession of this value is not necessarily an authorization to access the associated archived data object or evidence record. It must be possible to authenticate requests and responses, e.g. to enable LTAs to render an authorization decision. This may be accomplished using transport security mechanisms. Requests, in particular retrieval or deletion requests, may be rejected if the requestor is not authorized. An authorization policy must be defined and observed by the long-term archive service. An LTA may disallow physical deletion as a matter of policy. The format for the acknowledgements must allow the identification of the archiving provider and the participating client. The LTA must provide an acknowledgement of deposit that permits the submitter to confirm the correct data was accepted by the LTA. This proof need not be provided immediately. 4.1.2 Rationale Submission, retrieval, query state and deletion of archived data objects are necessary basic functions of a long-term archive service. Deletion may be disallowed due to procedural difficulties in fulfilling the request. For example, an archived data object may be Wallace, et al. Expires January 18, 2006 [Page 9] Internet-Draft Archive Requirements July 2005 storage on write-once media along with other records that are not subject to deletion. Acknowledgements may not be provided immediately due to implementation of a grace period. A generic query state mechanism should be provided to address such situations. For example, a submission response may indicate that a submission has been accepted and a subsequent query state response may indicate a submission has completed all necessary preservation steps. 4.2 Enable management of archived data objects 4.2.1 Functional Requirements A long-term archive service must permit clients to request the following basic operations: - specify an archivation period for submitted data objects - extend or shorten the archivation period for an archived data object - specify metadata associated with an archived data object - specify an archive policy under which the submitted data should be handled It should be possible to extend or shorten the archivation period after the initial submission. It should be possible to express an archivation period in terms of time, an event or a combination of time and event. Submitters should be able to specify metadata that, for example, can be used to enable retrievers to render the data correctly, to locate data in an archive or to place data in a particular context. Examples include, classification codes, type of format, contributors, title, author, date. Alternatively, such information may be included in the content of an archived data object. If a long-term archive service does not support a requested policy, it must return an error indication. A service must provide an indication of the archive policy enforced by the service. 4.2.2 Rationale Submission, retrieval and deletion of archived data objects are necessary basic functions of a long-term archive service. Specification and management of the archivation period is necessary Wallace, et al. Expires January 18, 2006 [Page 10] Internet-Draft Archive Requirements July 2005 to avoid unnecessary preservation activities. 4.3 Provide evidence records that support demonstration of data integrity 4.3.1 Functional Requirements A long-term archive service must be capable of providing evidence that can be used to demonstrate the integrity of data for which it is responsible from the time it received the data until the expiration of the archivation period of the data. This may be achieved by providing evidence records that support the long-term non-repudiation of data existence at and integrity since a point in time, e.g. in the case of legal disputes. The evidence record should contain sufficient information to enable the validity of an archived data object's characteristics to be demonstrated to an arbitrator. The characteristics subject to verification will vary. For example, authentication of an originator may not be possible in all cases. Evidence records must be structured such that modifications to an archived data object or its evidence record can be detected, including modifications made by administrators of an LTA. 4.3.2 Rationale Supporting non-repudiation of data existence, integrity and origin is a primary purpose of a long-term archive service. Evidence may be generated, or otherwise obtained, by the service providing the evidence to a retriever. A long-term archive service need not be capable of providing all evidence necessary to produce a non- repudiation proof and in some cases should not be trusted to provide all necessary information. For example, trust anchors [RFC3280] and algorithm security policies should be provided by other services. An LTA that is trusted to provide trust anchors could forge an evidence records verified using those trust anchors. Demonstration that data has not been altered while in the care of a long-term archive service is a first step towards supporting non- repudiation of data. Certification services support cases in which data must be modified, e.g. translation or format migration. An LTA may provide certification services. The requirements for certification services are defined in [CERTSRV] 4.4 Operate per a long-term archive policy Wallace, et al. Expires January 18, 2006 [Page 11] Internet-Draft Archive Requirements July 2005 4.4.1 Functional Requirements [CRW: Policy is probably the biggest unresolved area. This section still needs to identify the principle components of policy and identify which components, if any, should apply on a per document basis and/or which be configurable by a submitter or modifier. Mechanism-specific policy details (such as a cryptographic maintenance policy) could be defined in document describing the mechanism or in this document if neutrality is not necessary.] A long-term archive service must operate per a long-term archive service policy that defines characteristics of the implementation of the long-term archive service. A long-term archive service policy contains several components, including: - Archived data object maintenance policy - Authorization policy - Service policy A long-term archive service policy must include specifications of the preservation activities performed for archived data objects subject to the policy. A maintenance policy should define rules for the following operational aspects: preservation activity triggers, default archivation period, default handling upon expiration of archivation period. Maintenance policies should include mechanism-specific details describing LTA operation. For example, where cryptographic mechanisms are employed, a cryptographic maintenance policy should be defined. An authorization policy should define the entities permitted to exercise services provided by the LTA, including who is permitted to submit, retrieve or manage specific archived data objects. A service policy defines the types of services provided by an LTA, including acceptable data types, description of requests that may be accepted and deletion procedures. A long-term archive service must be able to provide information identifying the policies relevant for a given archived data object. 4.4.2 Rationale Similar to a certificate policies [RFC3647], which are identified using object identifiers, a long-term archive policy provides a Wallace, et al. Expires January 18, 2006 [Page 12] Internet-Draft Archive Requirements July 2005 shorthand means of technically identifying a set of rules that govern operation of a long-term archive service. Over the course of many years, the policies under which an LTA operates may undergo modification. Thus, an evidence record may feature multiple indications of policies active at various points during the life of an archived data object. 4.5 Support data confidentiality 4.5.1 Functional Requirements [CRW: This section has not been discussed much but could be a tricky requirement to meet. In particular, the need for confidentiality between submitter and service complicates preservation and may require additional interfaces.] A long-term archive service must provide means to ensure confidentiality of archived data objects, including confidentiality between the submitter and the long-term archive service. An LTA must provide a means for accepting encrypted data such that future preservation activities apply to the original, unencrypted data. Encryption or other methods of providing confidentiality must not pose a risk to the associated evidence record. 4.5.2 Rationale Individuals may wish to use the services of a commercial long-term service without disclosing data to the commercial service. However, access to the original data may be necessary to perform some preservation activities. 4.6 Provide means to transfer data and evidence from one service to another 4.6.1 Functional Requirements It must be possible to submit data along with previously generated evidence, i.e. to support transfer of data from one archive to another. A long-term archive service must support the transfer of archived data objects, evidence and evidence records from one service to another. It must be possible for evidence records to span multiple providers over the course of time without losing value as evidence. 4.6.2 Rationale Before the end of an archived data object's archivation period, a Wallace, et al. Expires January 18, 2006 [Page 13] Internet-Draft Archive Requirements July 2005 long-term archive service may cease operation. In such cases, it must be possible for the archived data object (and any associated evidence) to be transferred to another service that will continue preservation of the data until the end of the archivation period. Submitters may change service providers before the end of an archived data object's archivation period. In such cases, it must be possible for the submitter to transfer an archived data object and all associated evidence from the original LTA to a new LTA. 4.7 Support operations on groups of data objects 4.7.1 Functional Requirements An LTA should support submission of groups of data objects. Submitters should be able to indicate which data objects belong together, i.e. comprise a group, and retrievers should be able to retrieve one, some or all members of a group of data objects. It should be possible to provide evidence for groups of archived data objects. For example, it should be possible to archive a document file and a signature file together such that they are covered by the same evidence record. Where an LTA operates upon groups of data objects, non-repudiation proof must still be available for each archived data object separately. 4.7.2 Rationale In many cases data objects belong together. Examples include: - a document file and an associated signature file, which are two separate objects - TIF-files representing pages of a document - a document file and an evidence file (possibly generated by another LTA or certification service) - a document and its translation to another format or language In these cases, it is to the best advantage to handle these data objects as a group. Wallace, et al. Expires January 18, 2006 [Page 14] Internet-Draft Archive Requirements July 2005 5. Operational Considerations A long-term archive service must be able to work efficiently even for large amounts of archived data objects. In order to limit expenses and to achieve high performance, it may be desirable to minimize the use of trusted third parties, e.g. LTA operations should be designed to limit the number of time-stamps required to provide the desired level of service. Necessity to access archived data objects should be minimized. It may only be necessary access to the archived data objects if the archived data objects are requested by users or if hash algorithms used for indexing or evidence record generation become insecure. Wallace, et al. Expires January 18, 2006 [Page 15] Internet-Draft Archive Requirements July 2005 6. Security Considerations Data is the principal asset protected by a long-term archive service. The principle threat addressed by a long-term archive service is undetected loss of data integrity. In cases where signature verification relies on a PKI, certificate revocation could retroactively invalidate previously verified signatures. An LTA may implement measures to support such claims by an alleged signer, e.g. collection of revocation information after a grace period during which compromise can be reported or preservation of subsequent revocation information. When selecting access control mechanisms associated with data stored by a LTA, the lifespan of the archived data object should be considered. For example, the credentials of an entity that submitted data to an archive may not be available or valid when the data needs to be retrieved. During lifespan of an archived data object, formats may cease to be supported. Software components to process data, including content or signatures, may no longer available. This could be a problem particularly if non-standard formats are used or proprietary processing is employed. The submitter should take care to avoid such problems. For example, the submitter (or other authorized entity) could periodically retrieve data, convert the data and re-submit it in new format. Additional mechanisms, applications or tools may be needed to preserve the value of evidence records associated with original archived data object. Other specifications of LTANS, in particular certification services will address these problems. Some applications may require processing of a chain of archive policies present in an evidence record, e.g. to ensure that compatible policies were used throughout the lifetime of an archived data object. [CRW: It was suggested that this last item be moved to the main body of the document and addressed in detail. To what extent, if any, should automated policy processing of this sort be supported?] Wallace, et al. Expires January 18, 2006 [Page 16] Internet-Draft Archive Requirements July 2005 7. Acknowledgements Thanks to members of the LTANS mailing list for review of earlier drafts and many suggestions. In particular, thanks to Larry Masinter, Denis Pinkas and Peter Sylvester for review and suggestions. Wallace, et al. Expires January 18, 2006 [Page 17] Internet-Draft Archive Requirements July 2005 8. References 8.1 Normative References [RFC3667] Bradner, S., "IETF Rights in Contributions", RFC 3667, February 2004. 8.2 Informative References [CERTSRV] Schmidt, A., Gondrom, T., and L. Masinter, "Requirements for Certification Services", October 2004. [RFC3029] Adams, C., Sylvester, P., Zolotarev, M., and R. Zuccherato, "Internet X.509 Public Key Infrastructure Data Validation and Certification Server Protocols", RFC 3029, February 2001. [RFC3161] Adams, C., Cain, P., Pinkas, D., and R. Zuccherato, "Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP)", RFC 3161, August 2001. [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002. [RFC3647] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S. Wu, "Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework", RFC 3647, November 2003. Authors' Addresses Carl Wallace Orion Security Solutions Suite 300 1489 Chain Bridge Road McLean, VA 22101 Fax: +1(703)917-0260 Email: cwallace@orionsec.com Wallace, et al. Expires January 18, 2006 [Page 18] Internet-Draft Archive Requirements July 2005 Ulrich Pordesch Fraunhofer Gesellschaft Dolivostrasse 15 Darmstadt, Germany D-64293 Email: ulrich.pordesch@zv.fraunhofer.de Ralf Brandner InterComponentWare AG Otto-Hahn-Strabe 3 Walldorf, Germany 69190 Email: ralf.brandner@intercomponentware.com Wallace, et al. Expires January 18, 2006 [Page 19] Internet-Draft Archive Requirements July 2005 Appendix A. Application scenarios Below are several example application scenarios demonstrating one or more of the basic service features mentioned above. A.1 Archive service supporting long-term non-repudiation A long-term archive service may store data objects, such as signed or unsigned documents, for authenticated users. It may generate time stamps for these data objects and obtain verification data during the archivation period or until a deletion request is received from an authorized entity. A.2 Pure long-term non-repudiation service A long-term archive service may only guarantee non-repudiation of existence of data by periodically generating time stamps and obtaining verification data. It stores data objects (e.g. documents and signatures) locally only for the purpose of non-repudiation and does not function as a document archive for users. It does not support retrieval and deletion of data objects. A.3 Long-term Archive Service as part of an internal network A long-term archive service may be part of an enterprise network. The network provider and archive service may be part of the same institution. In this case, the service should obtain non-repudiation evidence from a third party. An internally generated acknowledgement may be viewed worthless. A.4 Long-term Archive External Service A long-term archive service may be provided over the Internet for enterprises or consumers. In this case, archiving and providing evidence (via time-stamps or other means) may be adduced by one organization and its own technical infrastructure without using external services. Wallace, et al. Expires January 18, 2006 [Page 20] Internet-Draft Archive Requirements July 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Wallace, et al. Expires January 18, 2006 [Page 21]