--- 1/draft-ietf-openpgp-rfc2440bis-14.txt 2006-02-04 17:19:10.000000000 +0100 +++ 2/draft-ietf-openpgp-rfc2440bis-15.txt 2006-02-04 17:19:10.000000000 +0100 @@ -1,55 +1,74 @@ Network Working Group Jon Callas Category: INTERNET-DRAFT PGP Corporation -draft-ietf-openpgp-rfc2440bis-14.txt -Expires January 2006 Lutz Donnerhacke -July 2005 +draft-ietf-openpgp-rfc2440bis-15.txt +Expires April 2006 Lutz Donnerhacke +October 2005 Obsoletes: 1991, 2440 Hal Finney PGP Corporation Rodney Thayer OpenPGP Message Format - draft-ietf-openpgp-rfc2440bis-14.txt + draft-ietf-openpgp-rfc2440bis-15.txt Copyright (C) The Internet Society (2005). -Status of this Memo +IPR Claim Notice - This document is an Internet-Draft and is in full conformance with - all provisions of Section 10 of RFC 2026. + 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. + + 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. + +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/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. -IPR Claim Notice - - 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. - -IESG Note +IANA Considerations This document defines many tag values, yet it doesn't describe a mechanism for adding new tags (for new features). Traditionally the Internet Assigned Numbers Authority (IANA) handles the allocation of new values for future expansion and RFCs usually define the procedure to be used by the IANA. However there are subtle (and not so subtle) interactions that may occur in this protocol between new features and existing features which result in a significant reduction in over all security. Therefore this document does not define an extension procedure. Instead requests to define new tag @@ -70,23 +89,23 @@ OpenPGP software uses a combination of strong public-key and symmetric cryptography to provide security services for electronic communications and data storage. These services include confidentiality, key management, authentication, and digital signatures. This document specifies the message formats used in OpenPGP. Table of Contents - Status of this Memo 1 IPR Claim Notice 1 - IESG Note 1 + Status of this Memo 1 + IANA Considerations 2 Abstract 2 Table of Contents 3 1. Introduction 6 1.1. Terms 6 2. General functions 6 2.1. Confidentiality via Encryption 7 2.2. Authentication via Digital signature 7 2.3. Compression 8 2.4. Conversion to Radix-64 8 2.5. Signature-Only Applications 8 @@ -113,27 +132,27 @@ 4.2.2.1. One-Octet Lengths 15 4.2.2.2. Two-Octet Lengths 15 4.2.2.3. Five-Octet Lengths 15 4.2.2.4. Partial Body Lengths 15 4.2.3. Packet Length Examples 16 4.3. Packet Tags 16 5. Packet Types 17 5.1. Public-Key Encrypted Session Key Packets (Tag 1) 17 5.2. Signature Packet (Tag 2) 18 5.2.1. Signature Types 18 - 5.2.2. Version 3 Signature Packet Format 20 + 5.2.2. Version 3 Signature Packet Format 21 5.2.3. Version 4 Signature Packet Format 23 - 5.2.3.1. Signature Subpacket Specification 23 + 5.2.3.1. Signature Subpacket Specification 24 5.2.3.2. Signature Subpacket Types 25 5.2.3.3. Notes on Self-Signatures 25 5.2.3.4. Signature creation time 26 - 5.2.3.5. Issuer 26 + 5.2.3.5. Issuer 27 5.2.3.6. Key expiration time 27 5.2.3.7. Preferred symmetric algorithms 27 5.2.3.8. Preferred hash algorithms 27 5.2.3.9. Preferred compression algorithms 27 5.2.3.10.Signature expiration time 27 5.2.3.11.Exportable Certification 28 5.2.3.12.Revocable 28 5.2.3.13.Trust signature 28 5.2.3.14.Regular expression 29 5.2.3.15.Revocation key 29 @@ -198,23 +217,23 @@ 12.2.1. Compression Preferences 62 12.2.2. Hash Algorithm Preferences 63 12.3. Plaintext 63 12.4. RSA 63 12.5. DSA 63 12.6. Elgamal 64 12.7. Reserved Algorithm Numbers 64 12.8. OpenPGP CFB mode 64 13. Security Considerations 65 14. Implementation Nits 68 - 15. Authors and Working Group Chair 69 + 15. Authors' Addresses 69 16. References (Normative) 70 - 17. References (Non-Normative) 71 + 17. References (Non-Normative) 72 18. Full Copyright Statement 72 1. Introduction This document provides information on the message-exchange packet formats used by OpenPGP to provide encryption, decryption, signing, and key management functions. It is a revision of RFC 2440, "OpenPGP Message Format", which itself replaces RFC 1991, "PGP Message Exchange Formats." @@ -860,22 +879,25 @@ Implementations SHOULD accept V3 signatures. Implementations SHOULD generate V4 signatures. Note that if an implementation is creating an encrypted and signed message that is encrypted to a V3 key, it is reasonable to create a V3 signature. 5.2.1. Signature Types There are a number of possible meanings for a signature, which are - specified in a signature type octet in any given signature. These - meanings are: + specified in a signature type octet in any given signature. See + section 5.2.4, "Computing Signatures," for detailed information on + how to compute and verify signatures of each type. + + These meanings are: 0x00: Signature of a binary document. This means the signer owns it, created it, or certifies that it has not been modified. 0x01: Signature of a canonical text document. This means the signer owns it, created it, or certifies that it has not been modified. The signature is calculated over the text data with its line endings converted to . @@ -912,21 +934,21 @@ certification authority to issue fine-grained claims. Most OpenPGP implementations make their "key signatures" as 0x10 certifications. Some implementations can issue 0x11-0x13 certifications, but few differentiate between the types. 0x18: Subkey Binding Signature This signature is a statement by the top-level signing key that indicates that it owns the subkey. This signature is calculated directly on the subkey itself, not on any User ID or other - packets. A signature that binds a signing subkey also has an + packets. A signature that binds a signing subkey SHOULD have an embedded signature subpacket in this binding signature which contains a 0x19 signature made by the signing subkey on the primary key. 0x19 Primary Key Binding Signature This signature is a statement by a signing subkey, indicating that it is owned by the primary key. This signature is calculated directly on the primary key itself, and not on any User ID or other packets. @@ -950,22 +972,23 @@ revoked. A revoked subkey is not to be used. Only revocation signatures by the top-level signature key that is bound to this subkey, or by an authorized revocation key, should be considered valid revocation signatures. 0x30: Certification revocation signature This signature revokes an earlier User ID certification signature (signature class 0x10 through 0x13) or direct-key signature (0x1F). It should be issued by the same key that issued the revoked signature or an authorized revocation key. - The signature should have a later creation date than the - signature it revokes. + The signature is computed over the same data as the certificate + that it revokes, and should have a later creation date than that + certificate. 0x40: Timestamp signature. This signature is only meaningful for the timestamp contained in it. 0x50: Third-Party Confirmation signature. This signature is a signature over some other OpenPGP signature packet(s). It is analogous to a notary seal on the signed data. A third-party signature SHOULD include Signature Target subpacket(s) to give easy identification. Note that we really do @@ -1087,56 +1110,62 @@ The body of a version 4 Signature Packet contains: - One-octet version number (4). - One-octet signature type. - One-octet public key algorithm. - One-octet hash algorithm. + - Two-octet scalar octet count for following hashed subpacket + data. Note that this is the length in octets of all of the + hashed subpackets; a pointer incremented by this number will + skip over the hashed subpackets. + - Hashed subpacket data set. (zero or more subpackets) - Two-octet scalar octet count for the following unhashed subpacket data. Note that this is the length in octets of all of the unhashed subpackets; a pointer incremented by this number will skip over the unhashed subpackets. - Unhashed subpacket data set. (zero or more subpackets) - Two-octet field holding the left 16 bits of the signed hash value. - One or more multiprecision integers comprising the signature. This portion is algorithm specific, as described above. - The data being signed is hashed, and then the signature data from - the version number through the hashed subpacket data (inclusive) is - hashed. The resulting hash value is what is signed. The left 16 - bits of the hash are included in the signature packet to provide a - quick test to reject some invalid signatures. + The concatenation of the data being signed and the signature data + from the version number through the hashed subpacket data + (inclusive) is hashed. The resulting hash value is what is signed. + The left 16 bits of the hash are included in the signature packet to + provide a quick test to reject some invalid signatures. There are two fields consisting of signature subpackets. The first field is hashed with the rest of the signature data, while the second is unhashed. The second set of subpackets is not cryptographically protected by the signature and should include only advisory information. The algorithms for converting the hash function result to a signature are described in a section below. 5.2.3.1. Signature Subpacket Specification - A subpacket data set consists of zero or more signature subpackets, - preceded by a two-octet scalar count of the length in octets of all - the subpackets; a pointer incremented by this number will skip over - the subpacket data set. + A subpacket data set consists of zero or more signature subpackets. + In signature packets the subpacket data set is preceded by a + two-octet scalar count of the length in octets of all the + subpackets. A pointer incremented by this number will skip over the + subpacket data set. Each subpacket consists of a subpacket header and a body. The header consists of: - the subpacket length (1, 2, or 5 octets) - the subpacket type (1 octet) and is followed by the subpacket specific data. @@ -1668,50 +1697,51 @@ This subpacket contains a complete signature packet body as specified in section 5.2 above. It is useful when one signature needs to refer to, or be incorporated in, another signature. 5.2.4. Computing Signatures All signatures are formed by producing a hash over the signature data, and then using the resulting hash in the signature algorithm. - The signature data is simple to compute for document signatures - (types 0x00 and 0x01), for which the document itself is the data. - For standalone signatures, this is a null string. + For binary document signatures (type 0x00), the document data is + hashed directly. For text document signatures (type 0x01), the + document is canonicalized by converting line endings to , + and the resulting data is hashed. When a signature is made over a key, the hash data starts with the octet 0x99, followed by a two-octet length of the key, and then body of the key packet. (Note that this is an old-style packet header for a key packet with two-octet length.) A subkey binding signature (type 0x18) or primary key binding signature (type 0x19) then hashes the subkey using the same format as the main key (also using 0x99 as the first octet). Key revocation signatures (types 0x20 and 0x28) hash only the key being revoked. - When a signature is made over a signature packet, the hash data - starts with the octet 0x88, followed by the four-octet length of the - signature, and then the body of the signature packet. The unhashed - subpacket data of the signature packet being hashed is not included - in the hash and the unhashed subpacket data length value is set to - zero. (Note that this is an old-style packet header for a signature - packet with the length-of-length set to zero). - A certification signature (type 0x10 through 0x13) hashes the User ID being bound to the key into the hash context after the above data. A V3 certification hashes the contents of the User ID or attribute packet packet, without any header. A V4 certification hashes the constant 0xb4 for User ID certifications or the constant 0xd1 for User Attribute certifications, followed by a four-octet number giving the length of the User ID or User Attribute data, and then the User ID or User Attribute data. + When a signature is made over a signature packet (type 0x50), the + hash data starts with the octet 0x88, followed by the four-octet + length of the signature, and then the body of the signature packet. + (Note that this is an old-style packet header for a signature packet + with the length-of-length set to zero). The unhashed subpacket data + of the signature packet being hashed is not included in the hash and + the unhashed subpacket data length value is set to zero. + Once the data body is hashed, then a trailer is hashed. A V3 signature hashes five octets of the packet body, starting from the signature type field. This data is the signature type, followed by the four-octet signature time. A V4 signature hashes the packet body starting from its first field, the version number, through the end of the hashed subpacket data. Thus, the fields hashed are the signature version, the signature type, the public key algorithm, the hash algorithm, the hashed subpacket length, and the hashed subpacket body. @@ -1899,23 +1929,23 @@ V3 keys are deprecated. They contain three weaknesses in them. First, it is relatively easy to construct a V3 key that has the same key ID as any other key because the key ID is simply the low 64 bits of the public modulus. Secondly, because the fingerprint of a V3 key hashes the key material, but not its length, there is an increased opportunity for fingerprint collisions. Third, there are minor weaknesses in the MD5 hash algorithm that make developers prefer other algorithms. See below for a fuller discussion of key IDs and fingerprints. - V2 keys are identical to V3 keys except for the deprecated V3 keys - except for the version number. An implementation MUST NOT generate - them and may accept or reject them as it sees fit. + V2 keys are identical to the deprecated V3 keys except for the + version number. An implementation MUST NOT generate them and may + accept or reject them as it sees fit. The version 4 format is similar to the version 3 format except for the absence of a validity period. This has been moved to the signature packet. In addition, fingerprints of version 4 keys are calculated differently from version 3 keys, as described in section "Enhanced Key Formats." A version 4 packet contains: - A one-octet version number (4). @@ -2041,22 +2071,22 @@ checksum is deprecated; an implementation SHOULD NOT use it, but should rather use the SHA-1 hash denoted with a usage octet of 254. The reason for this is that there are some attacks on the private key that can undetectably modify the secret key. Using a SHA-1 hash prevents this. 5.6. Compressed Data Packet (Tag 8) The Compressed Data packet contains compressed data. Typically, this packet is found as the contents of an encrypted packet, or following - a Signature or One-Pass Signature packet, and contains literal data - packets. + a Signature or One-Pass Signature packet, and contains a literal + data packet. The body of this packet consists of: - One octet that gives the algorithm used to compress the packet. - The remainder of the packet is compressed data. A Compressed Data Packet's body contains an block that compresses some set of packets. See section "Packet Composition" for details on how messages are formed. @@ -2066,22 +2096,22 @@ implementation uses more bits of compression, PGP V2.6 cannot decompress it. ZLIB-compressed packets are compressed with RFC 1950 ZLIB-style blocks. 5.7. Symmetrically Encrypted Data Packet (Tag 9) The Symmetrically Encrypted Data packet contains data encrypted with a symmetric-key algorithm. When it has been decrypted, it contains - other packets (usually literal data packets or compressed data - packets, but in theory other Symmetrically Encrypted Data Packets or + other packets (usually a literal data packet or compressed data + packet, but in theory other Symmetrically Encrypted Data Packets or sequences of packets that form whole OpenPGP messages). The body of this packet consists of: - Encrypted data, the output of the selected symmetric-key cipher operating in OpenPGP's variant of Cipher Feedback (CFB) mode. The symmetric cipher used may be specified in an Public-Key or Symmetric-Key Encrypted Session Key packet that precedes the Symmetrically Encrypted Data Packet. In that case, the cipher @@ -2182,21 +2212,21 @@ implementation. Trust packets SHOULD NOT be emitted to output streams that are transferred to other users, and they SHOULD be ignored on any input other than local keyring files. 5.11. User ID Packet (Tag 13) A User ID packet consists of UTF-8 text that is intended to represent the name and email address of the key holder. By - convention, it includes an RFC 822 mail name, but there are no + convention, it includes an RFC 2822 mail name, but there are no restrictions on its content. The packet length in the header specifies the length of the User ID. 5.12. User Attribute Packet (Tag 17) The User Attribute packet is a variation of the User ID packet. It is capable of storing more types of data than the User ID packet which is limited to text. Like the User ID packet, a User Attribute packet may be certified by the key owner ("self-signed") or any other key owner who cares to certify it. Except as noted, a User @@ -2937,22 +2967,21 @@ An OpenPGP message is a packet or sequence of packets that corresponds to the following grammatical rules (comma represents sequential composition, and vertical bar separates alternatives): OpenPGP Message :- Encrypted Message | Signed Message | Compressed Message | Literal Message. Compressed Message :- Compressed Data Packet. - Literal Message :- Literal Data Packet | - Literal Message, Literal Data Packet. + Literal Message :- Literal Data Packet. ESK :- Public Key Encrypted Session Key Packet | Symmetric-Key Encrypted Session Key Packet. ESK Sequence :- ESK | ESK Sequence, ESK. Encrypted Data :- Symmetrically Encrypted Data Packet | Symmetrically Encrypted Integrity Protected Data Packet Encrypted Message :- Encrypted Data | ESK Sequence, Encrypted Data. @@ -3393,31 +3422,38 @@ * Some technologies mentioned here may be subject to government control in some countries. * In winter 2005, Serge Mister and Robert Zuccherato from Entrust released a paper describing a way that the "quick check" in OpenPGP CFB mode can be used with a random oracle to decrypt two octets of every cipher block [MZ05]. They recommend as prevention not using the quick check at all. Many implementers have taken this advice to heart for any data - that is both symmetrically encrypted, but also the session key - is public-key encrypted. In this case, the quick check is not + that is symmetrically encrypted and for which the session key is + public-key encrypted. In this case, the quick check is not needed as the public key encryption of the session key should guarantee that it is the right session key. In other cases, the - implementation should use the quick check with care. On the one - hand, there is a danger to using it if there is a random oracle - that can leak information to an attacker. On the other hand, it - is inconvenient to the user to be informed that they typed in - the wrong passphrase only after a petabyte of data is decrypted. - There are many cases in cryptographic engineering where the - implementer must use care and wisdom, and this is another. + implementation should use the quick check with care. + + On the one hand, there is a danger to using it if there is a + random oracle that can leak information to an attacker. In + plainer language, there is a danger to using the quick check if + timing information about the check can be exposed to an + attacker, particularly via an automated service that allows + rapidly repeated queries + + On the other hand, it is inconvenient to the user to be informed + that they typed in the wrong passphrase only after a petabyte of + data is decrypted. There are many cases in cryptographic + engineering where the implementer must use care and wisdom, and + this is one. 14. Implementation Nits This section is a collection of comments to help an implementer, particularly with an eye to backward compatibility. Previous implementations of PGP are not OpenPGP-compliant. Often the differences are small, but small differences are frequently more vexing than large differences. Thus, this is a non-comprehensive list of potential problems and gotchas for a developer who is trying to be backward-compatible. @@ -3453,21 +3489,21 @@ * If an implementation is using zlib to interoperate with PGP 2.x, then the "windowBits" parameter should be set to -13. * PGP 2.6.X and 5.0 do not trim trailing whitespace from a "canonical text" signature. They only remove it from cleartext signatures. These signatures are not OpenPGP compliant -- OpenPGP requires trimming the whitespace. If you wish to interoperate with PGP 2.6.X or PGP 5, you may wish to accept these non-compliant signatures. -15. Authors and Working Group Chair +15. Authors' Addresses The working group can be contacted via the current chair: Derek Atkins IHTFP Consulting, Inc. 6 Farragut Ave Somerville, MA 02144 USA Email: derek@ihtfp.com Tel: +1 617 623 3745 @@ -3467,40 +3503,32 @@ Derek Atkins IHTFP Consulting, Inc. 6 Farragut Ave Somerville, MA 02144 USA Email: derek@ihtfp.com Tel: +1 617 623 3745 The principal authors of this draft are: Jon Callas - Email: jon@callas.org - Tel: +1 (408) 448-6801 Lutz Donnerhacke IKS GmbH Wildenbruchstr. 15 07745 Jena, Germany EMail: lutz@iks-jena.de - Tel: +49-3641-675642 Hal Finney - Network Associates, Inc. - 3965 Freedom Circle - Santa Clara, CA 95054, USA - Email: hal@finney.org Rodney Thayer - Email: rodney@tillerman.to This memo also draws on much previous work from a number of other authors who include: Derek Atkins, Charles Breed, Dave Del Torto, Marc Dyksterhouse, Gail Haspert, Gene Hoffman, Paul Hoffman, Raph Levien, Colin Plumb, Will Price, David Shaw, William Stallings, Mark Weaver, and Philip R. Zimmermann. 16. References (Normative) @@ -3531,62 +3560,74 @@ fips180-2/fips180-2withchangenotice.pdf> [FIPS186] Digital Signature Standard (DSS) (FIPS PUB 186-2). [HAC] Alfred Menezes, Paul van Oorschot, and Scott Vanstone, "Handbook of Applied Cryptography," CRC Press, 1996. + [IDEA] Lai, X, "On the design and security of block ciphers", ETH Series in Information Processing, J.L. Massey (editor), Vol. 1, Hartung-Gorre Verlag Knostanz, Technische Hochschule (Zurich), 1992 [ISO10646] ISO/IEC 10646-1:1993. International Standard -- Information technology -- Universal Multiple-Octet Coded Character Set (UCS) -- Part 1: Architecture and Basic Multilingual Plane. + [JFIF] JPEG File Interchange Format (Version 1.02). Eric Hamilton, C-Cube Microsystems, Milpitas, CA, September 1, 1992. - [RFC822] Crocker, D., "Standard for the format of ARPA - Internet text messages", STD 11, RFC 822, August - 1982. [RFC1423] Balenson, D., "Privacy Enhancement for Internet Electronic Mail: Part III: Algorithms, Modes, and Identifiers", RFC 1423, October 1993. + [RFC1641] Goldsmith, D. and M. Davis, "Using Unicode with MIME", RFC 1641, July 1994. + [RFC1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness Recommendations for Security", RFC 1750, December 1994. + [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification version 1.3.", RFC 1951, May 1996. + [RFC1991] Atkins, D., Stallings, W. and P. Zimmermann, "PGP Message Exchange Formats", RFC 1991, August 1996. + [RFC2045] Borenstein, N. and N. Freed, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies.", RFC 2045, November 1996. + [RFC2144] Adams, C., "The CAST-128 Encryption Algorithm", RFC 2144, May 1997. + [RFC2279] Yergeau., F., "UTF-8, a transformation format of Unicode and ISO 10646", RFC 2279, January 1998. + [RFC2437] B. Kaliski and J. Staddon, " PKCS #1: RSA Cryptography Specifications Version 2.0", RFC 2437, October 1998. + + [RFC2822] Resnick, P., "Internet Message Format", RFC 2822. + [RFC3156] M. Elkins, D. Del Torto, R. Levien, T. Roessler, "MIME Security with OpenPGP", RFC 3156, August 2001. + [SCHNEIER] Schneier, B., "Applied Cryptography Second Edition: protocols, algorithms, and source code in C", 1996. + [TWOFISH] B. Schneier, J. Kelsey, D. Whiting, D. Wagner, C. Hall, and N. Ferguson, "The Twofish Encryption Algorithm", John Wiley & Sons, 1999. 17. References (Non-Normative) [BLEICHENBACHER] Bleichenbacher, Daniel, "Generating Elgamal signatures without knowing the secret key," Eurocrypt 96. Note that the version in the proceedings has an error. A revised version is @@ -3601,38 +3644,39 @@ against PGP and GnuPG" http://www.counterpane.com/pgp-attack.html [MZ05] Serge Mister, Robert Zuccherato, "An Attack on CFB Mode Encryption As Used By OpenPGP," IACR ePrint Archive: Report 2005/033, 8 Feb 2005 http://eprint.iacr.org/2005/033 [RFC1983] Malkin, G., "Internet Users' Glossary", FYI 18, RFC 1983, August 1996. + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Level", BCP 14, RFC 2119, March 1997. 18. Full Copyright Statement - Copyright 2005 by The Internet Society. All Rights Reserved. + Copyright (C) 2005 by The Internet Society. 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 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. + 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. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of