Internet-Draft J. Marchioni Working Group: Individual ARX, Inc draft-digital-signature-system-deployment-00 Y. Itzhaki Category: Informational T. Yas'ur Obsoletes: None Algorithmic Research, Ltd Expires: 29 March 2009 30 September 2008 Approach to Digital Signature Systems Deployment Status of This Memo 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/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html 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. Abstract Conventional deployments store keys on PC hard disks, application- server hard disks, or in tokens, and also introduce complications for user enrollment and management. User and administrator frustration with the conventional approach has cramped development of a market for PKI. As a result, PKI has not reached its utilization potential and is far from becoming ubiquitous. This document describes architecture for deployment of secure and efficient digital signature capabilities based on a centralized key- management approach and emphasizes the importance of not disrupting existing identity and authentication management and application infrastructure. An alternative architecture is documented here so that PKI deployments will lower their associated administrative burdens and deliver improved scalability. Table of Contents. 1. Introduction 1 2. The Digital Signature Solution Deployment 2 2.1. Operations and Infrastructure 2 2.1.1. Identity Proofing 2 2.1.2. Signature-User Enrollment 2 2.1.3. RA Proxy 3 2.1.4. Key and Certificate Management 3 2.1.5. Certificate Management Options 3 2.1.6. Revocation, CRLs and OCSP 4 2.1.7. Automatic Refresh: Keys and/or Certificates 4 2.1.8. Re-keying 4 2.2. Applications and User Authentication 5 2.2.1. Key and Signature Services for the Application 5 2.2.2. Signature and Verification Process 6 2.2.3. User Authentication 6 2.2.4. Middleware and Programmatic Interfaces 6 3. Security Considerations 7 4. Conclusion 8 Informative References 8 IPR Statement 11 Acknowledgement 11 Authors Addresses 12 Copyright Notice 12 Marchioni & Itzhaki Informational [Page 1] Internet-Draft Digital Signature System Deployment 30 September 2008 1. Introduction. This document presents an approach to deploying digital signature solutions, but does not mandate use of a solution-specific or PKI- specific identity proofing policy, procedure, enrollment software, or PKI-specific authentication scheme. The approach leverages an organization's pre-established user and authentication infrastructure to drive the management of end-user signature credentials i.e., management of signature keys and certificates. The described architecture results in minimum impact by the signature PKI on business operations. While the architecture mandates use of PKI and digital signature standards, it also allows deployment of several optional security and middleware components that can be used to meet requirements of a broad diversity of security policies, applications, and business processes, and include: o FIPS-140 [REF] evaluated hardware options to provide extra physical and programmatic access control and integrity protection for private keys and digital-signature operations; o SHS [REF] is mandated and provides integrity protection of signed objects (documents or data); o Triple-DES [REF] and AES [REF] are symmetric-cryptographic options that provide confidentiality and integrity protection of signature private keys; o X.509 v3 certificates and X.509 v2 CRLs [REF] are mandatory to ensure signature verification and support non-repudiation under off the shelf applications; o RSA (1024 to 4096-bit) [REF] and ECDSA [REF] are options that provide integrity and non-repudiation protection of digital signatures on user-signed data, certificates and CRLs; o SSL/TLS [REF] options provide confidentiality and integrity protection of signature object hash values and signature blocks sent between the application and key server; o PKCS#1 [REF] and PKCS#7 [REF] are used to enable signature verification by off the shelf applications; o PKCS#10 [REF] is used for public-key certification requests to enable key certification operations; o PKCS#11 [REF], OASIS DSS [REF], CAPI [REF], and ASSP [REF] are middleware-interface options to allow a diversity of applications access to signature services. Marchioni & Itzhaki Informational [Page 2] Internet-Draft Digital Signature System Deployment 30 September 2008 2. The Digital Signature Solution Deployment. 2.1. Operations and Infrastructure. +-------------+ +------------------+ +--------------------+ | | | | | | | Established | | Established +---/ | | | ID-Proofing +=====+ User-Management | / | Key & Certificate | | Procedure | ^ | System | /---+ Server | | | | | | ^ | | +-------------+ | +------------------+ | +--------------------+ | | Domain-Established LDAP or Directory-Specific Standard Operating Procedure Protocol Figure 1. Example of Enrollment, Key and Certificate Management 2.1.1. Identity Proofing. Most organizations have an established, documented and standard operating procedure for identity proofing that requires in-person verification. These procedures are typically under the control of screening departments such as human- resources, or those that screen suppliers and/or customers. When a person's identity is verified (proofed) that person is enrolled in the organization's established user/supplier/customer database, typically an LDAP-enabled directory or database, and an identity credential is issued. The PKI or digital-signature system deployed must not disrupt these established identity and authentication management(IAM) policies, procedures and infrastructure, rather the signature PKI must be driven by the established infrastructure. 2.1.2. Signature-User Enrollment. The deployment virtualizes an organization's established identity-directory (or database) services as the registration authority (RA) (i.e., RA proxy) for the signature PKI. [Note the deployment described here may leverage a range of pre-existing identity-credentialing systems to authenticate users and manage their digital-signature credentials, i.e., signature key pair and signature certificate]. All signature-key and signature-certificate provisioning and management functions must be performed transparently and securely for the end user and systems administrator (see next section). Marchioni & Itzhaki Informational [Page 3] Internet-Draft Digital Signature System Deployment 30 September 2008 2.1.3. Registration Authority (RA) Proxy. The key and certificate server must listen to a set of events on the user directory (e.g., new user, remove user, change user details, etc.) and translate these routine administrative operations into signature-key and certificate-management events (e.g., generate key pair, revoke private key, issue/revoke certificate, etc.), without the need for additional PKI-specific administrator intervention. 2.1.4. Key and Certificate Management. The deployment provides a network-attached multi-user server for key and certificate generation and storage, and for private-key operations. Such a server can be any basic hardware server, or one that has undergone FIPS-140 evaluation for higher assurance in key protection. Signature keys and certificates are generated, stored and managed inside the server, and private keys are never exposed outside this server. If such a server has also been evaluated for FIPS 140 security, it can provide hardware security without the need for personal-hardware tokens. In fact some servers, depending on FIPS level (FIPS 140-2 defines four levels of security, simply named "Level 1" to "Level 4"), can be viewed as a large network-attached smart card that generates and stores all users' signature credentials, and executes all signature (private-key) operations. Furthermore, user (and administrator) can only use and access their own signature key(s), and have access to none other. Access for key usage is controlled by the authentication scheme chosen by the organization, [see sec 2.2.3], and the specific server's protection profile. The operational impact is an elimination of the high burden in logistics, cost, help-desk support, and lack of user acceptance, associated with the purchase, provisioning, distribution, and management of individual public-key hardware or software tokens. 2.1.5. Certificate Management Options. Certificate management can be provided either by an embedded Certification Authority (CA) in the key and certificate server (the server), or by one of two optional middleware (or procedural) interfaces between the server and an external CA: (i) a middleware interface that allows the server to act as an RA Proxy between the organization's user management infrastructure and the external CA by making PKCS#10 key- certification requests from the server on behalf of each user directly to the external CA; (ii) a middleware (or procedure) can allow the embedded CA to be established as a subordinate to a Root CA by exporting its public key (e.g., subject = subordinate CA xyz) and submitting a PKCS#10 key-certification request to an external Root CA. Marchioni & Itzhaki Informational [Page 4] Internet-Draft Digital Signature System Deployment 30 September 2008 Organizations can then have the option to securely and transparently manage and control their own CA or get certificate-management services from an independent third party CA. Furthermore, the systems administrator and users have no training obstacles or added burdens related to PKI-service management and use, regardless of the chosen CA option. Under this approach (RA Proxy), the organization need not change their current policies, procedures, and systems for (a) identity proofing and management, and (b) user enrollment/revocation. Thus the deployment of the digital-signature system and PKI does not negatively impact established policy and infrastructure, nor end- user and administrator routines or business operations. 2.1.6. Revocation, CRLs and OCSP. This approach mandates a user is revoked by revoking his/her private key, i.e., the private key is immediately deleted by the server. Therefore, at the time of revocation the user no longer has a capability to make even one more signature. Hence, all signatures that verify with that user's certificate have been made when the user had valid signature privileges, and not after. At the time the private key is revoked the user's certificate is also revoked and placed on the CRL. However, the need to manage and reconcile CRLs under this approach is less important resulting in a savings of processing, administrative, and CRL-distribution overhead. Furthermore, if all key management in the PKI followed a centralized approach the need for OCSP responders might be eliminated, resulting in an added efficiency in signature verification, i.e., those examining signatures need not be online to verify signatures (see section 2.2.2. below). In any event, as long as the conventional approach is used there will be a need for CRLs and OCSP. 2.1.7 Automatic Refresh: Keys and/or Certificates. Since keys and certificates are managed centrally, the key-certificate server can automatically refresh keys (i.e., generate new and revoke old certificates (i.e., issue new certificate with new validity period) upon expiration without the delays or logistics issues associated with private keys and certificates managed on computer hard drives or personal hardware tokens such as smart cards and USB sticks . 2.1.8. Re-keying. As security policies evolve, it may become necessary to migrate from 1024-bit RSA to 2048-bit RSA, or from RSA to ECDSA. Conventional deployment approaches mandate the provisioning and distribution of physical personal signature-key media, either software or hardware tokens. These deployments leave the administrator with a serious logistical burden for re-keying. Under such conventional deployments, the administrator first needs to provision new key tokens for each user, and then carefully manage the timing of their activation and swapping with tokens already in the hands of the end users. Marchioni & Itzhaki Informational [Page 5] Internet-Draft Digital Signature System Deployment 30 September 2008 In the event that re-keying is required for signature keys, the centralized approach offers an efficient method to re-keying the user community. Since no personal signature-key media has been distributed (see section 2.2.1. below), all users can be re-keyed at once from the central network-attached key server without delay or logistical issues. 2.2. Applications and User Authentication. +---------------+ +---------------+ +--------------------+ | | | | | | | Application +=====+ Desktop +---/ | Key & Certificate | | Desktop | ^ | Middleware | /---+ Server | | | | | | ^ | | +---------------+ | +---------------+ | +--------------------+ | | Middleware Interface Authenticated e.g.,PKCS#11/CAPI SSL or TLS Figure 2. Deployment Under the Desktop or Server Application +---------------+ +----------------------+ | | | | | Application | | Key & Certificate | | Web Browser +---/ | Server with | | | /---+ Web Services | | | ^ | | +---------------+ | +----------------------+ | Authenticated SSL or TLS Figure 3. Deployment Under the Web Application 2.2.1. Key and Signature Services for the Application. The server "appears" either as a local key media (e.g., USB stick or smart card) to desktop applications, or as a Web-service key media to any Web application. The server must present itself to the application as a standard key media using middleware that is compatible with the application. Such middleware is typically based on either a PKCS#11, CAPI, OASIS DSS Web Service, or other Web service interface like ASSP. Marchioni & Itzhaki Informational [Page 6] Internet-Draft Digital Signature System Deployment 30 September 2008 The functions normally provided by a software token, public-key smart card or USB stick, (i.e., secure key generation, key storage, signature operation, certificate storage, etc.) are provided by the network-attached server via the middleware interfaces indicated above. 2.2.2. Signature and Verification Process. Documents (or data) can be hashed on the user's computer, this results in significant savings of network bandwidth as compared to sending entire documents to the server to be hashed. At the initiation of a signature operation, an authenticated SSL/TLS session is established between the user's computer and the server. A SSL/TLS session is established only after the user (i.e., the signer) has been authenticated by answering an identity challenge. The secure session provides confidentiality and integrity for the hash sent to the server, and for the signature block and certificate returned to the user's application. The signature block and certificate are then embedded in the document. When the signature needs to be validated all that is needed is the signed document and the application software to calculate signature verification. 2.2.3. User Authentication. A number of options for identity challenge may be considered. To avoid disruption in pre-existing user authentication policy and infrastructure, the options include: (a) Kerberos SSO,(b) simple username/password-PIN, and (c) the following two-factor authentication options: (i) RADIUS [REF] or DIAMETER [REF] protocol with one-time password token, (ii) challenge-response protocol with identity smart card, and (iii) biometrics. Therefore, the organization can choose a level of user- authentication security that matches the requirements of their application, but nothing less secure than what is needed is made available under the deployment. 2.2.4. Middleware and Programmatic Interfaces. Standard interfaces allow deployments to cost-effectively dovetail digital signature capabilities into pre-existing as well as new applications, and identity-management infrastructures. Another advantage of standard interfaces is allowing for one vendor's solution to be replaced by a solution from another vendor with less disruption, eliminating vendor lock. The deployment also considers what is familiar to end-users in terms of visual indication of a signature. Therefore, there is consideration for a one-time capture and centrally stored handwritten graphical signature image (e.g., from an electronic- signature-pad or ePen interface, or by loading the image from a .jpg or .bmp file) for placement with every digital signature. This approach provides an added visual convenience to end users, and encourages user adoption and routine use of standard digital signatures. Marchioni & Itzhaki Informational [Page 7] Internet-Draft Digital Signature System Deployment 30 September 2008 When needed, middleware with standard and application-compatible APIs and Web services can provide the following functions for customized signature-enabled application development: o Sign/validate signatures in application-specific document types; o Sign/validate a single file or data buffer; o Check certificate validity; o Enumerate/manage certificates; o Manage graphical electronic signatures; o Manage users. 3. Security Considerations. The overall risk to a business process must be assessed and balanced with scalability objectives before defining procedures or choosing security-technology mechanisms. The goal is to deliver the needed level of security from a business-needs perspective, but not less (i.e., lowering security), or more (i.e., driving up costs), resulting in a deployment that matches what is required. The trust or security of any deployment is based first and foremost on a documented operating procedure for user enrollment, identity, and authentication management. An equally important security consideration is the proper training of the stakeholders (e.g., systems administrators, security officers, and users). If a stakeholder deviates from established procedure either because he/she is poorly trained or does so intentionally, they may defeat many security-technology countermeasures. Time sources for document and certificate signing are provided by the internal domain or an external source. Some external time sources provide a higher reliability and level of trust, however, they carry a cost overhead that may not be tolerable for all businesses. Trust in internal-domain time sources can be increased through management policy and security mechanisms. Policy and security mechanisms can prohibit the use of PCs as time sources, and prevent tampering with clocks. An effective option for raising confidence in internal-domain time source is the clock of a FIPS- evaluated secure key server. Since keys are securely accessed for signature operations, time stamps can be provided from this protected source from within the domain. Concerning user authentication, simple user name and password schemes provide less security than two-factor schemes like one-time password tokens, identity smart cards, or biometrics. Furthermore, server-based user authentication is generally viewed as more secure because servers can be less vulnerable to trojan-horse or virus software than the typical user's PC. Marchioni & Itzhaki Informational [Page 8] Internet-Draft Digital Signature System Deployment 30 September 2008 Hardware protection for keys can be provided at various levels depending on the requirements of the business or the value of its transactions. For example, key servers that have been evaluated for FIPS 140-2 level 3 and smart cards provide hardware protection for keys. The designers of such hardware consider such scenarios in which hardware might fall into the hands of an attacker, or user keys might be exposed to a systems administrator. As a precaution countermeasures are built into their respective key-protection hardware. 4. Conclusion. Affordable and scalable PKI deployment strategies are needed. This alternative approach emphasizes consideration for pre-existing user- management, authentication, and application infrastructures and offers more access to PKI than conventional methods. Informative References. [AES] National Institute of Standards and Technology (NIST), "FIPS Publication 197: Advanced Encryption Standard", http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf, 2001 November 26. [ASSP] "Adobe Signature Services Protocol" (ASSP), 2007, Available only from Adobe Systems, Inc. See Adobe http://www.adobe.com. [CAPI] R. Coleridge, "The Cryptography API, or How to Keep a Secret", http://msdn2.microsoft.com/en-us/library/ms867086.aspx, August 1996. [CMS] R. Housley, "Cryptographic Message Syntax", IETF RFC 3852, http://www.ietf.org/rfc/rfc3852.txt, July 2004. [DIAMETER] P. Calhoun, J. Loughney, E. Guttman, G. Zorn, J. Arkko, "Diameter Base Protocol", http://www.rfc-editor.org/rfc/rfc3588.txt, September 2003. [Ellison] C. Ellison, "Improvements on Conventional PKI Wisdom", Proceedings of the 1st Annual PKI Research Workshop, pp. 165-176, August 2002. [FIPS140] National Institute of Standards and Technology (NIST), "FIPS Publication 140-2: Security Requirements for Cryptographic Modules", http://csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf, May 2001. [Gupta] S. Gupta, "Security Characteristics of Cryptographic Mobility Solutions", Proceedings of the 1st Annual PKI Research Workshop, pp. 117-126, August 2002. Marchioni & Itzhaki Informational [Page 9] Internet-Draft Digital Signature System Deployment 30 September 2008 [Gutmann] P. Gutmann, "Plug-and-Play PKI: A PKI your Mother can Use", Proceedings of the 12th USENIX Security Symposium, pp. 45-58, August 2003. [IPSEC] S. Kent and R. Atkinson, "Security Architecture for the Internet Protocol", IETF RFC 2401, http://www.ietf.org/rfc/rfc2401.txt, November 1998. [JCA] Sun Microsystems, Inc., "Java Cryptography Architecture, API Specification & Reference", http://java.sun.com/j2se/1.4.2/docs/guide/ security/CryptoSpec.html, August 2002. [Kerberos] Microsoft Corp., "Windows 2000 Kerberos Authentication", http://www.microsoft.com/technet/prodtechnol/windows2000serv/deploy/con feat/kerberos.mspx [LDAP] K. Zeilenga, "Lightweight Directory Access Protocol", IETF RFC 4510, http://www.ietf.org/rfc/rfc4510.txt, June 2006. [Lorch] M. Lorch, J. Basney and D. Kafura, "A Hardware-secured Credential Repository for Grid PKIs", 4th IEEE/ACM International Symposium on Cluster Computing and the Grid, pp. 640-647, April 2004. [Marchesini] J. Marchesini, S.W. Smith, M. Zhao, "Keyjacking: Risks of the Current Client-side Infrastructure", Proceedings of the 2nd Annual PKI Research Workshop, pp. 128-144, April 2003. [NAMU] S. Turner and R. Housley, "Implementing Email Security and Tokens: Current Standards, Tools, and Practices" pp.159-160, Wiley Publishing, 2008. [Nielsen] R. Nielsen, "Observations from the Deployment of a Large Scale PKI", Proceedings of the 4th Annual PKI Research Workshop, pp. 159-165, August 2005. [NTP] D. L. Mills, "Network Time Protocol", IETF RFC 1305, http://www.ietf.org/rfc/rfc1305.txt, March 1992. [OASIS] S. Drees et al, "Digital Signature Service Core Protocols, Elements, and Bindings", OASIS Digital Signature Services Technical Committee Draft, http://docs.oasis-open.org/dss/v1.0/oasis-dss-1.0- core-spec-cd-r5.pdf, August 2006. [PKCS1] RSA Laboratories, "PKCS #1 v.21: RSA Cryptography Standard", ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-1/pkcs-1v2-1.pdf, June 2002. [PKCS7] RSA Laboratories, "PKCS #7 v.1.6: "Cryptographic Message Syntax Standard", ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-7/pkcs- 7v16.pdf, May 1997. Marchioni & Itzhaki Informational [Page 10] Internet-Draft Digital Signature System Deployment 30 September 2008 [PKCS10] RSA Laboratories, "PKCS #10 v.1.7: "Certification Request Syntax Standard", ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-10/pkcs- 10v1_7d1.pdf, March, 2000 [PKCS11] RSA Laboratories, "PKCS #11 v2.20: Cryptographic Token Interface Standard", ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-11/v2- 20/pkcs-11v2-20.pdf, June 2004. [Perrin] T. Perrin, L. Bruns, J. Moreh and T. Olkin, "Delegated Cryptography, Online Trusted Third Parties, and PKI", Proceedings of the 1st Annual PKI Research Workshop, pp. 97-116, August 2002. [Pope] N. Pope, J. C. Cruellas, "Oasis Digital Signature Services: Digital Signing without the Headaches," IEEE Internet Computing, vol. 10, no. 5, pp. 81-84, September/October 2006. [RADIUS] C. Rigney et al, "Remote Authentication Dial In User Service", IETF RFC 2865, http://www.ietf.org/rfc/rfc2865.txt, June 2000. [Resnitzky] U. Resnitzky, "The Directory-Enabled PKI Appliance: Digital Signatures Made Simple, Approach and Real World Experience" Feb 2007. [RSA] R.L. Rivest, A. Shamir and L. Adleman, "A method for obtaining digital signatures and public-key cryptosystems", Communications of the ACM, vol. 21, no. 2, pp. 120-126, February 1978. [RSA] [ECDSA] National Institute of Standards and Technology (NIST), "FIPS Publication 186-2: Digital Signature Standard (DSS)", http://csrc.nist.gov/publications/fips/fips186-2/fips186-2-change1.pdf, January 2007 [SAPI] ARX, "SAPI(r) Signature API Programmer's Guide Version 4.1", Pub. No. CSN.SAPI.V32.1206, Available on request from info@arx.com, December 2006. [Sandhu] R. Sandhu, M Bellare and R. Ganesan, "Password-Enabled PKI: Virtual Smartcards versus Virtual Soft Tokens", Proceedings of the 1st Annual PKI Research Workshop, pp. 89-96, August 2002. [Schneier] B. Schneier, "Security Risks of Centralization", Crypto-Gram, http://www.schneier.com/crypto-gram-0403.html#11, March 2004. [SHS] National Institute of Standards and Technology (NIST), "FIPS Publication 180-2: Secure Hash Standard", http://csrc.nist.gov/publications/fips/fips180-2/fips180-2.pdf, August 2002. Marchioni & Itzhaki Informational [Page 11] Internet-Draft Digital Signature System Deployment 30 September 2008 [TLS] T. Dierks and E. Rescorla, "The Transport Layer Security (TLS) Protocol", IETF RFC 4346, http://www.ietf.org/rfc/rfc4346.txt, April 2006. [Whitten] A. Whitten and J.D. Tygar, "Why Johnny Can't Encrypt: A Usability Evaluation of PGP 5.0", Proceedings of the 8th USENIX Security Symposium, pp. 169-184, August 1999. Intellectual Property. 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. Acknowledgement. Development of this informational RFC was sponsored by ARX, Inc. and Algorithmic Research, Ltd. Marchioni & Itzhaki Informational [Page 12] Internet-Draft Digital Signature System Deployment 30 September 2008 Authors' Addresses John Marchioni ARX, Inc. 855 Folsom Street Suite 939 San Francisco, CA 94107 USA EMail: johnmarc@arx.com Yair Itzhaki Tal Yas'ur Algorithmic Research, Ltd. 10 Nevatim Street Petach Tikva, 49561 Israel EMail: yair@arx.com EMail: tal@arx.com Copyright (C) The IETF Trust (2008). 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. 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, THE IETF TRUST 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.