Network Working Group R. Naffah Internet-Draft Forge Research Expires: December 18, 2002 K. Burdis June 19, 2002 Algorithm naming draft-naffah-naming-00 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 December 18, 2002. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract This document describes a process for registering cryptographic algorithm names and parameters to ease referencing of such information from IETF Drafts and RFCs. Naffah & Burdis Expires December 18, 2002 [Page 1] Internet-Draft Algorithm naming June 2002 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . 4 2. The objectives . . . . . . . . . . . . . . . . . . . . . 6 3. The big picture . . . . . . . . . . . . . . . . . . . . 7 4. Proposed templates . . . . . . . . . . . . . . . . . . . 8 4.1 The NTEXT entity . . . . . . . . . . . . . . . . . . . . 8 4.2 The algorithm root element . . . . . . . . . . . . . . . 8 4.2.1 The 'name' attribute . . . . . . . . . . . . . . . . . . 9 4.2.2 The 'type' attribute . . . . . . . . . . . . . . . . . . 9 4.3 The 'alias' element . . . . . . . . . . . . . . . . . . 10 4.4 The 'oid' element . . . . . . . . . . . . . . . . . . . 10 4.5 The 'vulnerabilities' element . . . . . . . . . . . . . 10 4.6 The 'patents' element . . . . . . . . . . . . . . . . . 10 4.7 The 'test-vectors' element . . . . . . . . . . . . . . . 10 4.8 Algorithm properties . . . . . . . . . . . . . . . . . . 11 4.8.1 Category-related properties - 'category' element . . . . 12 4.8.1.1 Hash function properties . . . . . . . . . . . . . . . . 12 4.8.1.1.1 The 'hash.output.size' capability property . . . . . . . 12 4.8.1.2 Symmetric key block cipher properties . . . . . . . . . 12 4.8.1.2.1 The 'cipher.block.size' capability property . . . . . . 12 4.8.1.2.2 The 'cipher.key.size' capability property . . . . . . . 12 4.8.1.3 Mode of operation properties . . . . . . . . . . . . . . 13 4.8.1.3.1 The 'mode.output.size' capability property . . . . . . . 13 4.8.1.3.2 The 'mode.underlying.cipher' configuration property . . 13 4.8.2 Specific algorithm-related properties - 'own' element . 13 5. How to fully qualify an algorithm . . . . . . . . . . . 14 5.1 The long notation . . . . . . . . . . . . . . . . . . . 14 5.2 The shorthand notation . . . . . . . . . . . . . . . . . 14 5.3 A formal description of the notations . . . . . . . . . 15 6. How to add new categories . . . . . . . . . . . . . . . 17 References . . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . 19 A. Initial entries . . . . . . . . . . . . . . . . . . . . 20 A.1 Hash functions . . . . . . . . . . . . . . . . . . . . . 20 A.1.1 MD5 . . . . . . . . . . . . . . . . . . . . . . . . . . 20 A.1.2 Secure Hash Standard (SHS) . . . . . . . . . . . . . . . 23 A.1.3 Whirlpool . . . . . . . . . . . . . . . . . . . . . . . 23 A.2 Symmetric key block cipher algorithms . . . . . . . . . 24 A.2.1 Advanced Encryption Standard (AES) . . . . . . . . . . . 24 A.2.2 Rijndael . . . . . . . . . . . . . . . . . . . . . . . . 24 A.3 Block cipher modes of operation . . . . . . . . . . . . 24 A.3.1 Cipher Block Chaining (CBC) . . . . . . . . . . . . . . 24 A.3.2 Cipher Feedback (CFB) . . . . . . . . . . . . . . . . . 24 A.3.3 Output Feedback (OFB) . . . . . . . . . . . . . . . . . 24 B. The full DTD . . . . . . . . . . . . . . . . . . . . . . 25 Full Copyright Statement . . . . . . . . . . . . . . . . 28 Naffah & Burdis Expires December 18, 2002 [Page 2] Internet-Draft Algorithm naming June 2002 1. Introduction Many algorithms and protocols described in IETF Drafts and RFCs can use, or are capable of using, more than one lower level cryptographic algorithm and primitive. For example HMAC [RFC2104] describes a Message Authentication Code (MAC) algorithm that uses an underlying "iterative cryptographic hash function." Similarly, SRP [RFC2945] describes an "abstract protocol" which can be implemented in different ways, depending on an underlying hash function. Another such "generic" algorithm is the [ICM] block cipher mode of operation. At a higher level still, protocols are defined and/or proposed that can be constructed using "generic" algorithms. For example [SASL- SRP] requires the peers to negotiate, among other things, an underlying hash function for use with SRP, and an HMAC algorithm if/ when integrity protection is required. To address this issue, [ID-nits] in the "Variant Algorithm Definitions" section, proposes the following: "If you specify multiple algorithms for a particular function: For example, if there are multiple compression algorithms, encryption algorithms, representation formats, etc., consider * A robust way to enumerate these, preferably with space for future assignments by the Internet Assigned Number Authority. * Consider re-using an existing IANA registry instead of creating a new one, since this leads to less confusion between different registries that have similar items." An inspection of the IANA registries related to algorithm naming shows the following: 1. HTTP Digest Algorithm Values. http://www.iana.org/assignments/http-dig-alg 2. Internet Key Exchange (IKE) Attributes. http://www.iana.org/assignments/ipsec-registry 3. "Magic Numbers" for ISAKMP Protocol. http://www.iana.org/assignments/isakmp-registry 4. ONE TIME PASSWORD PARAMETERS. http://www.iana.org/assignments/otp-parameters 5. TELNET OPTIONS. http://www.iana.org/assignments/telnet-options Naffah & Burdis Expires December 18, 2002 [Page 3] Internet-Draft Algorithm naming June 2002 All of these make reference to a certain specification and/or protocol. None of them provide a central repository that can be used by current or future IETF Drafts and RFCs to unambiguously reference algorithms and primitives used within their specifications. Furthermore, specifying an algorithm name in itself is not enough to completely describe how such an algorithm may be used. For example, some block cipher algorithms are capable of operating with more than one block size and/or accepting more than one key size --e.g. [RIJNDAEL]. Similarly, some hash functions can generate more than one output size --e.g. [SHS]. Rather than create new IANA registries for each individual specification, we propose that a new single IANA registry be created to store security-related naming information that can be referenced by multiple specifications. This registry would hold information such as the name of the algorithm, its reference paper(s), its possible variations and test vector(s). This document also proposes a way for naming these algorithms and their combinations. Outside the IETF, [SCAN] aims at achieving similar objectives, albeit with a special emphasis on the "Java Cryptography Architecture." OIDs (Object Identifiers in ASN.1 parlance) are another way of referencing an algorithm. Unfortunately, not all desired or needed algorithms have an OID assigned to them. And if they do, the OID does not much help in obtaining the other types of information we are proposing. Naffah & Burdis Expires December 18, 2002 [Page 4] Internet-Draft Algorithm naming June 2002 2. The objectives Concentrate in one location, all relevant and available information about cryptographic algorithms, grouped by their primary type, and including all possible and permissible parameter values and test vectors. Furthermore, a section keeping up-to-date information about discovered vulnerabilities and/or weaknesses would be valuable for designers of high/er level protocols. Finally, a section about patent issues would be very helpful for organisations wishing/ planning to use the algorithm in commercial products. In working towards achieving the above, other secondary objectives would be met in the process, such as: 1. Reduce confusion: Some cryptographic algorithms have more than one variant, or have undergone different standardisation efforts leading to more than just one type of operation. For example, the block cipher Output Feedback (OFB) mode of operation is described in the literature ([HAC], chapter 7) as commonly used in one of two ways: per ISO 10116, and per FIPS 81. 2. Facilitate inter-operability: Concentrating in one location, directly --through copies of the documents themselves-- or indirectly --through links to other locations on the net where copies of the documents can be found-- including test-vectors would facilitate achieving inter-operability of different implementations. 3. Improve security: Application and protocol designers would easily find the latest discovered vulnerabilities about algorithms and possible replacements/alternatives. Naffah & Burdis Expires December 18, 2002 [Page 5] Internet-Draft Algorithm naming June 2002 3. The big picture The collection of entries should be accessible from as little roots as possible. We propose having just one root accessible from the IANA number assignment page --i.e. http://www.iana.org/assignments/. Let's call this root/page: "Cryptographic Algorithms." Under that heading, different sections would group algorithms, according to their main intended use. We propose the following list of categories as a start: 1. Hash algorithms. 2. Symmetric key block cipher algorithms. 3. Block cipher modes of operations. In a later section we present a proposed process for adding new categories to this initial list. Naffah & Burdis Expires December 18, 2002 [Page 6] Internet-Draft Algorithm naming June 2002 4. Proposed templates We propose an xml file as the template for the algorithm naming entry, with a DTD that includes all data types and elements defined in [RFC2629]. In the next sections we shall only describe the additional data types and elements introduced by this document. 4.1 The NTEXT entity This data type is used to encode the algorithm name and alias. It represents a textual data with no whitespace characters. 4.2 The algorithm root element At the root of an algorithm name entry is the 'algorithm' root element which looks like so: ... ... ... ... ... ... ... ... ... ... ... ... ... ... ...
...
...
... Naffah & Burdis Expires December 18, 2002 [Page 7] Internet-Draft Algorithm naming June 2002 ... ... ... ... ... ... ... ... ... ... ... ... ... 4.2.1 The 'name' attribute A mandatory, textual, single-valued property that gives the name with which the algorithm, with all its variations, if it has any, is commonly known by; e.g. SHS. This is usually the formal name that the designers/inventors of the algorithm call it by. 4.2.2 The 'type' attribute A mandatory, textual, single-valued property that gives the type of the algorithm. Permissible values are: o hash: To denote that the algorithm is a hash function. o cipher: To denote that the algorithm is a symmetric key block cipher. Naffah & Burdis Expires December 18, 2002 [Page 8] Internet-Draft Algorithm naming June 2002 o mode: To denote that the algorithm is a block cipher mode of operation. 4.3 The 'alias' element An optional, textual, multi-valued property that gives one or more other common and/or widely used name(s) for the algorithm. 4.4 The 'oid' element An optional, textual, single-valued property that gives, if assigned, the OBJECT IDENTIFIER (ASN.1 OID) of the algorithm. 4.5 The 'vulnerabilities' element An optional element which when present consists of one or more 'reference' elements similar in form to the 'references' and 'patents' elements. Each 'reference' element contained in this element would point to a published work describing a vulnerability and/or weakness discovered or known relating to the algorithm in question. 4.6 The 'patents' element An optional element which when present consists of one or more 'reference' elements similar in form to the 'references' and 'vulnerabilities' elements. Each 'reference' element contained in this element would point to a published work describing a patent issue related to the algorithm in question. 4.7 The 'test-vectors' element A mandatory, textual, multi-valued property that lists certified or sanctioned (by the algorithm author(s)) sets of specific input and initialisation parameters and values along with the associated expected result(s). We use the 'section' element in defining the contents of each 'test- vector' element contained in this one. We take advantage of the recursive nature of the 'section' element [RFC2629] to reduce duplication of data when defining test vector values. For example, to represent the encryption test vectors for the AES (128-bit key) in ECB mode, ([MODES], page 24), one would write the Naffah & Burdis Expires December 18, 2002 [Page 9] Internet-Draft Algorithm naming June 2002 following: ...
2b7e151628aed2a6abf7158809cf4f3c
6bc1bee22e409f96e93d7e117393172a
3ad77bb40d7a3660a89ecaf32466ef97
ae2d8a571e03ac9c9eb76fac45af8e51
f5d3d58503b9699de785895a96fdbaaf
30c81c46a35ce411e5fbc1191a0a52ef
43b1cd7f598ece23881b00e3ed030688
f69f2445df4f9b17ad2b417be66c3710
7b0c785e27e8ad3f8223207104725dd4
... ... ... 4.8 Algorithm properties Naffah & Burdis Expires December 18, 2002 [Page 10] Internet-Draft Algorithm naming June 2002 4.8.1 Category-related properties - 'category' element Every naming category has a set of attributes that all entries, grouped under it, would share. These attributes differ from one category to another. Properties for every category share a common prefix that easily allows a human reader to know the 'type' of algorithm name and attributes the property is for. We distinguish between 'capability' and 'configuration' properties. The first type of properties, listed in the next sections, describe the algorithm in terms of its capabilities, while, the latter type of properties (a) may not be known, or is irrelevant to the description of the algorithm, but (b) needs to be specified for fully specifiying an instance of that algorithm. We use a specific notation in designating these properties, based on a small alphabet which is a subset of the ASCII character set. 4.8.1.1 Hash function properties A cryptographic hash function is a mathematical transformation that takes as its input a message of variable length, and produces a fixed length output (see [HAC], chapter 9). 4.8.1.1.1 The 'hash.output.size' capability property A mandatory, numeric, multi-valued property that specifies the size(s), in bits, of the generated output of the hash function. 4.8.1.2 Symmetric key block cipher properties A symmetric key block cipher is a mathematical transformation of a fixed size input to a same size output result. Applying the transformation, using the same key material, on an output of a previous transformation yields the same input used for that transformation. 4.8.1.2.1 The 'cipher.block.size' capability property A mandatory, numeric, multi-valued property that lists the size(s), in bits, of the ciphertext (encryption) or plaintext (decryption) of the block cipher. 4.8.1.2.2 The 'cipher.key.size' capability property A mandatory, numeric, multi-valued property that lists the size(s), Naffah & Burdis Expires December 18, 2002 [Page 11] Internet-Draft Algorithm naming June 2002 in bits, of acceptable user-supplied key material for the block cipher algorithm. 4.8.1.3 Mode of operation properties Block cipher modes of operation allow using a fixed size output block cipher to process input sequences that are (a) longer than the cipher's block size (by partitioning the input sequence) or (b) smaller than the cipher's block size (when they are capable of producing, for each iteration, a small size output). Modes of operation, always operate on an underlying block cipher to produce their output. Their capabilities should hence be defined with reference to that underlying cipher. For example, Electronic Codebook (ECB) mode, has one output size which is that of its underlying cipher. 4.8.1.3.1 The 'mode.output.size' capability property A mandatory, numeric, multi-valued property that lists the size(s), in bits, of the ciphertext (encryption) or plaintext (decryption) of the mode of operation. Another alternative to the above 'enumeration' style definition, when the number of values is large, is to use a 'range' definition: lower bound, upper bound, and step. 4.8.1.3.2 The 'mode.underlying.cipher' configuration property The fully qualified name of a symmetric key block cipher. 4.8.2 Specific algorithm-related properties - 'own' element In addition to the above common and category-related properties, some algorithm may need to define their own properties. Naffah & Burdis Expires December 18, 2002 [Page 12] Internet-Draft Algorithm naming June 2002 5. How to fully qualify an algorithm Algorithms are named for (a) reference purposes, as well as (b) for configuration purposes. To illustrate how we propose to solve the naming problem, we shall use in the next sections the symmetric key block cipher [RIJNDAEL]. Rijndael is a variable block-size (128-, 192- and 256-bit), variable key-size (128-, 192- and 256-bit) symmetric key block cipher. 5.1 The long notation In a specification, where a symmetric key block cipher may be used, and where the designer has chosen Rijndael as the algorithm to use, with say 256-bit block size and 256-bit key size, the specification would state: ietf.algorithm.name=rijndael, ietf.cipher.block.size=192, ietf.cipher.key.size=256 In another situation, where the designer needs to specify the same block cipher but operating in Code Feedback (CFB) mode with 8-bit output size, the long notation may look like so: ietf.algorithm.name=cfb, ietf.mode.output.size=8, ietf.mode.underlying.cipher= ( ietf.algorithm.name=rijndael, ietf.cipher.block.size=192, ietf.cipher.key.size=256 ) 5.2 The shorthand notation The properties above, for the first example, can be written in a shorthand notation as follows: ietf.algorithm.name=rijndael(192,256) Again, using the shorthand notation for the second example produces: ietf.algorithm.name=cfb(8,rijndael(192,256)) Naffah & Burdis Expires December 18, 2002 [Page 13] Internet-Draft Algorithm naming June 2002 5.3 A formal description of the notations In the above examples, it is worth noting that while we used 'capability' properties in qualifying what type of algorithm instances we mean (and need), we used these properties for 'configuration' purposes. Specifically, while the 'cipher.block.size' is a multi-valued property, we used a notation to imply the usage of one value, among those listed in the capabilities, for the type of instance we're interested in. The following is an attempt to describe the two notation tyles used so far. Because we do not allow mixing the two styles, we shall define them separately. We do so using the Augmented BNF notation (ABNF) [RFC2234]. ; Ignorable whitespace HTAB = %x09 ; horizontal tab LF = %x0A ; linefeed CR = %x0D ; carriage return SP = %x20 DIGIT = %x30-39 ; 0-9 ALPHA = %x41-5A / %x61-7A ; A-Z / a-z CRLF = CR LF ; Internet standard newline WSP = SP / HTAB ; white space LWSP = *(WSP / CRLF WSP) ; linear white space (past newline) ; Symbols NAME_PROPERTY = "ietf.algorithm.name" ; Terminals identifier = ALPHA *(ALPHA / DIGIT) name = ALPHA *(ALPHA / DIGIT / "-") number = 1*DIGIT ; Non-terminals (Rules) fully-qualified-name = long-name / short-name long-name = name-specification *WSP *("," LWSP property-specification) name-specification = NAME_PROPERTY *WSP "=" *WSP name property-specification = capability-parameter / configuration-parameter Naffah & Burdis Expires December 18, 2002 [Page 14] Internet-Draft Algorithm naming June 2002 capability-parameter = property-name *WSP "=" *WSP number property-name = identifier *("." identifier) configuration-parameter = property-name *WSP "=" *WSP configuration-arg configuration-arg = "(" LWSP long-name LWSP ")" short-name = identifier [ "(" value *("," value) ")" ] value = number / short-name Naffah & Burdis Expires December 18, 2002 [Page 15] Internet-Draft Algorithm naming June 2002 6. How to add new categories [ TODO... ] Naffah & Burdis Expires December 18, 2002 [Page 16] Internet-Draft Algorithm naming June 2002 References [AES] National Institute of Standards and Technology, "Rijndael: NIST's Selection for the AES", December 2000, . [HAC] Menezes, A., van Oorschot, P. and S. Vanstone, "Handbook of Applied Cryptography", CRC Press, Inc., ISBN 0-8493-8523-7, 1997, . [http-dig-alg] "HTTP Digest Algorithm Values", January 2002, . [ICM] McGrew, D., "Integer Counter Mode", ID draft-mcgrew- saag-icm-00, November 2001, . [ID-nits] Baker, Fred., "Considerations for Internet Drafts - Variant Algorithm Definitions", April 1999, . [MODES] Dworkin, M., "Recommendation for Block Cipher Modes of Operation", September 1999, . [RFC1423] Balenson, D., "Privacy Enhancement for Internet Electronic Mail: Part III: Algorithms, Modes, and Identifiers", RFC 1423, February 1993, . [RFC2104] Krawczyk, H., "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 0014, RFC 2119, March 1997, . [RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997, . [RFC2945] Wu, T., "The SRP Authentication and Key Exchange System", RFC 2945, September 2000, . Naffah & Burdis Expires December 18, 2002 [Page 17] Internet-Draft Algorithm naming June 2002 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June 1999, . [RIJNDAEL] Daemen, Joan. and Vincent. Rijmen, "AES Proposal: Rijndael", September 1999, . [SASL-SRP] Burdis, K. and R. Naffah, "Secure Remote Password SASL Mechanism", ID draft-burdis-cat-srp-sasl-06, January 2002, . [SCAN] Hopwood, D., "Standard Cryptographic Algorithm Naming", June 2000, . [SHS] National Institute of Standards and Technology, "SECURE HASH STANDARD", May 2001, . Authors' Addresses Raif S. Naffah Forge Research Pty. Limited Suite 116, Bay 9 Locomotive Workshop, Australian Technology Park Cornwallis Street Eveleigh, NSW 1430 AU EMail: raif@forge.com.au Keith R. Burdis Naffah & Burdis Expires December 18, 2002 [Page 18] Internet-Draft Algorithm naming June 2002 Appendix A. Initial entries A.1 Hash functions A.1.1 MD5 iso(1) member-body(2) US(840) rsadsi(113549) digestAlgorithm(2) 5 The MD5 Message-Digest Algorithm Massachusetts Institute of Technology
Laboratory for Computer Science NE43-324 545 Technology Square Cambridge MA 02139-1986 USA rivest@theory.lcs.mit.edu
The MD5 algorithm takes as input a message of arbitrary length and produces as output a 128-bit "fingerprint" or "message digest" of the input. It is conjectured that it is computationally infeasible to produce two messages having the same hash, or to produce any message having a given prespecified target hash. The MD5 algorithm is intended for Naffah & Burdis Expires December 18, 2002 [Page 19] Internet-Draft Algorithm naming June 2002 digital signature applications, where a large file must be "compressed" in a secure manner before being encrypted with a private (secret) key under a public-key cryptosystem such as RSA. MD5 is designed to be quite fast on 32-bit machines. It does not require any large substitution tables, and can be coded quite compactly. MD5 is an extension of the MD4 hash algorithm. MD5 is slightly slower than MD4, but is more "conservative" in design. MD5 was designed because it was felt that MD4 was perhaps being adopted for use more quickly than justified by the existing critical review; because MD4 was designed to be exceptionally fast, it is "at the edge" in terms of risking successful cryptanalytic attack. MD5 backs off a bit, giving up a little in speed for a much greater likelihood of ultimate security. It incorporates some suggestions made by various reviewers, and contains additional optimizations. From : The MD5 algorithm is being placed in the public domain. The MD5 Message-Digest Algorithm Massachusetts Institute of Technology Naffah & Burdis Expires December 18, 2002 [Page 20] Internet-Draft Algorithm naming June 2002
""
d41d8cd98f00b204e9800998ecf8427e
"a"
0cc175b9c0f1b6a831c399e269772661
"abc"
900150983cd24fb0d6963f7d28e17f72
"message digest"
f96b697d7cb7938d525a2f31aaf161d0
"abcdefghijklmnopqrstuvwxyz"
c3fcd3d76192e4007dfb496cca67e13b
"ABCDEFGHIJKLMNOPQRSTUVWXYZ abcdefghijklmnopqrstuvwxyz 0123456789"
d174ab98d277d9f5a5611c2c9f419d9f
Naffah & Burdis Expires December 18, 2002 [Page 21] Internet-Draft Algorithm naming June 2002
"1234567890123456789012345678901234567890 1234567890123456789012345678901234567890"
57edf4a22be3c955ac49da2e2107b67a
The Status of MD5 After a Recent Attack RSA Security 128 A.1.2 Secure Hash Standard (SHS) [ TODO... ] A.1.3 Whirlpool [ TODO... ] Naffah & Burdis Expires December 18, 2002 [Page 22] Internet-Draft Algorithm naming June 2002 A.2 Symmetric key block cipher algorithms A.2.1 Advanced Encryption Standard (AES) [ TODO... ] A.2.2 Rijndael [ TODO... ] A.3 Block cipher modes of operation A.3.1 Cipher Block Chaining (CBC) [ TODO... ] A.3.2 Cipher Feedback (CFB) [ TODO... ] A.3.3 Output Feedback (OFB) [ TODO... ] Naffah & Burdis Expires December 18, 2002 [Page 23] Internet-Draft Algorithm naming June 2002 Appendix B. The full DTD Naffah & Burdis Expires December 18, 2002 [Page 24] Internet-Draft Algorithm naming June 2002 Naffah & Burdis Expires December 18, 2002 [Page 26] Internet-Draft Algorithm naming June 2002 Full Copyright Statement Copyright (C) The Internet Society (2002). All Rights Reserved. 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 developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Naffah & Burdis Expires December 18, 2002 [Page 27]