idnits 2.17.00 (12 Aug 2021) /tmp/idnits16429/draft-josefsson-rfc3548bis-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1193. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1170. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1177. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1183. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) -- The draft header indicates that this document obsoletes RFC3548, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 3, 2006) is 5861 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: '64' is mentioned on line 682, but not defined == Missing Reference: '0' is mentioned on line 934, but not defined -- Looks like a reference, but probably isn't: '0x100' on line 831 -- Obsolete informational reference (is this intentional?): RFC 2440 (ref. '5') (Obsoleted by RFC 4880) -- Obsolete informational reference (is this intentional?): RFC 2535 (ref. '6') (Obsoleted by RFC 4033, RFC 4034, RFC 4035) -- Obsolete informational reference (is this intentional?): RFC 3501 (ref. '8') (Obsoleted by RFC 9051) == Outdated reference: draft-ietf-dnsext-nsec3 has been published as RFC 5155 == Outdated reference: A later version (-05) exists of draft-ietf-cat-sasl-gssapi-01 Summary: 4 errors (**), 0 flaws (~~), 6 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Josefsson 3 Internet-Draft SJD 4 Obsoletes: 3548 (if approved) May 3, 2006 5 Expires: November 4, 2006 7 The Base16, Base32, and Base64 Data Encodings 8 draft-josefsson-rfc3548bis-03 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on November 4, 2006. 35 Copyright Notice 37 Copyright (C) The Internet Society (2006). 39 Keywords 41 Base Encoding, Base64, Base32, Base16, Hex. 43 Abstract 45 This document describes the commonly used base 64, base 32, and base 46 16 encoding schemes. It also discusses the use of line-feeds in 47 encoded data, use of padding in encoded data, use of non-alphabet 48 characters in encoded data, and use of different encoding alphabets. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Conventions Used in this Document . . . . . . . . . . . . . . 3 54 3. Implementation Discrepancies . . . . . . . . . . . . . . . . . 3 55 3.1. Line Feeds In Encoded Data . . . . . . . . . . . . . . . . 3 56 3.2. Padding Of Encoded Data . . . . . . . . . . . . . . . . . 4 57 3.3. Interpretation Of Non-Alphabet Characters In Encoded 58 data . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3.4. Choosing The Alphabet . . . . . . . . . . . . . . . . . . 4 60 4. Base 64 Encoding . . . . . . . . . . . . . . . . . . . . . . . 6 61 5. Base 64 Encoding With URL And Filename Safe Alphabet . . . . . 8 62 6. Base 32 Encoding . . . . . . . . . . . . . . . . . . . . . . . 8 63 7. Base 32 Encoding With Extended Hex Alphabet . . . . . . . . . 10 64 8. Base 16 Encoding . . . . . . . . . . . . . . . . . . . . . . . 11 65 9. Illustrations And Examples . . . . . . . . . . . . . . . . . . 12 66 10. Test Vectors . . . . . . . . . . . . . . . . . . . . . . . . . 13 67 11. ISO C99 Implementation Of Base64 . . . . . . . . . . . . . . . 14 68 11.1. Prototypes: base64.h . . . . . . . . . . . . . . . . . . . 14 69 11.2. Implementation: base64.c . . . . . . . . . . . . . . . . . 16 70 12. Security Considerations . . . . . . . . . . . . . . . . . . . 25 71 13. Changes Since RFC 3548 . . . . . . . . . . . . . . . . . . . . 25 72 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26 73 15. Copying Conditions . . . . . . . . . . . . . . . . . . . . . . 26 74 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 75 16.1. Normative References . . . . . . . . . . . . . . . . . . . 26 76 16.2. Informative References . . . . . . . . . . . . . . . . . . 26 77 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 28 78 Intellectual Property and Copyright Statements . . . . . . . . . . 29 80 1. Introduction 82 Base encoding of data is used in many situations to store or transfer 83 data in environments that, perhaps for legacy reasons, are restricted 84 to only US-ASCII [1] data. Base encoding can also be used in new 85 applications that do not have legacy restrictions, simply because it 86 makes it possible to manipulate objects with text editors. 88 In the past, different applications have had different requirements 89 and thus sometimes implemented base encodings in slightly different 90 ways. Today, protocol specifications sometimes use base encodings in 91 general, and "base64" in particular, without a precise description or 92 reference. Multipurpose Internet Mail Extensions (MIME) [4] is often 93 used as a reference for base64 without considering the consequences 94 for line-wrapping or non-alphabet characters. The purpose of this 95 specification is to establish common alphabet and encoding 96 considerations. This will hopefully reduce ambiguity in other 97 documents, leading to better interoperability. 99 2. Conventions Used in this Document 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 103 document are to be interpreted as described in [2]. 105 3. Implementation Discrepancies 107 Here we discuss the discrepancies between base encoding 108 implementations in the past, and where appropriate, mandate a 109 specific recommended behavior for the future. 111 3.1. Line Feeds In Encoded Data 113 MIME [4] is often used as a reference for base 64 encoding. However, 114 MIME does not define "base 64" per se, but rather a "base 64 Content- 115 Transfer-Encoding" for use within MIME. As such, MIME enforces a 116 limit on line length of base 64 encoded data to 76 characters. MIME 117 inherits the encoding from Privacy Enhanced Mail (PEM) [3] stating it 118 is "virtually identical", however PEM uses a line length of 64 119 characters. The MIME and PEM limits are both due to limits within 120 SMTP. 122 Implementations MUST NOT add line feeds to base encoded data unless 123 the specification referring to this document explicitly directs base 124 encoders to add line feeds after a specific number of characters. 126 3.2. Padding Of Encoded Data 128 In some circumstances, the use of padding ("=") in base encoded data 129 is not required nor used. In the general case, when assumptions on 130 size of transported data cannot be made, padding is required to yield 131 correct decoded data. 133 Implementations MUST include appropriate pad characters at the end of 134 encoded data unless the specification referring to this document 135 explicitly states otherwise. 137 The base64 and base32 alphabets use padding, as described below in 138 section 4 and 6, but the base16 alphabet does not need it, see 139 section 8. 141 3.3. Interpretation Of Non-Alphabet Characters In Encoded data 143 Base encodings use a specific, reduced, alphabet to encode binary 144 data. Non-alphabet characters could exist within base encoded data, 145 caused by data corruption or by design. Non-alphabet characters may 146 be exploited as a "covert channel", where non-protocol data can be 147 sent for nefarious purposes. Non-alphabet characters might also be 148 sent in order to exploit implementation errors leading to, e.g., 149 buffer overflow attacks. 151 Implementations MUST reject the encoded data if it contains 152 characters outside the base alphabet when interpreting base encoded 153 data, unless the specification referring to this document explicitly 154 states otherwise. Such specifications may, as MIME does, instead 155 state that characters outside the base encoding alphabet should 156 simply be ignored when interpreting data ("be liberal in what you 157 accept"). Note that this means that any adjacent carriage return/ 158 line feed (CRLF) characters constitute "non-alphabet characters" and 159 are ignored. Furthermore, such specifications MAY ignore the pad 160 character, "=", treating it as non-alphabet data, if it is present 161 before the end of the encoded data. If more than the allowed number 162 of pad characters are found at the end of the string, e.g., a base 64 163 string terminated with "===", the excess pad characters MAY also be 164 ignored. 166 3.4. Choosing The Alphabet 168 Different applications have different requirements on the characters 169 in the alphabet. Here are a few requirements that determine which 170 alphabet should be used: 172 o Handled by humans. Characters "0", "O" are easily confused, as 173 well as "1", "l" and "I". In the base32 alphabet below, where 0 174 (zero) and 1 (one) are not present, a decoder may interpret 0 as 175 O, and 1 as I or L depending on case. (However, by default it 176 should not, see previous section.) 178 o Encoded into structures that mandate other requirements. For base 179 16 and base 32, this determines the use of upper- or lowercase 180 alphabets. For base 64, the non-alphanumeric characters (in 181 particular "/") may be problematic in file names and URLs. 183 o Used as identifiers. Certain characters, notably "+" and "/" in 184 the base 64 alphabet, are treated as word-breaks by legacy text 185 search/index tools. 187 There is no universally accepted alphabet that fulfills all the 188 requirements. For an example of a highly specialized variant, see 189 IMAP [8]. In this document, we document and name some currently used 190 alphabets. 192 4. Base 64 Encoding 194 The following description of base 64 is derived from [3], [4], [5] 195 and [6]. This encoding may be referred to as "base64". 197 The Base 64 encoding is designed to represent arbitrary sequences of 198 octets in a form that allows the use of both upper- and lowercase 199 letters but need not be humanly readable. 201 A 65-character subset of US-ASCII is used, enabling 6 bits to be 202 represented per printable character. (The extra 65th character, "=", 203 is used to signify a special processing function.) 205 The encoding process represents 24-bit groups of input bits as output 206 strings of 4 encoded characters. Proceeding from left to right, a 207 24-bit input group is formed by concatenating 3 8-bit input groups. 208 These 24 bits are then treated as 4 concatenated 6-bit groups, each 209 of which is translated into a single character in the base 64 210 alphabet. 212 Each 6-bit group is used as an index into an array of 64 printable 213 characters. The character referenced by the index is placed in the 214 output string. 216 Table 1: The Base 64 Alphabet 218 Value Encoding Value Encoding Value Encoding Value Encoding 219 0 A 17 R 34 i 51 z 220 1 B 18 S 35 j 52 0 221 2 C 19 T 36 k 53 1 222 3 D 20 U 37 l 54 2 223 4 E 21 V 38 m 55 3 224 5 F 22 W 39 n 56 4 225 6 G 23 X 40 o 57 5 226 7 H 24 Y 41 p 58 6 227 8 I 25 Z 42 q 59 7 228 9 J 26 a 43 r 60 8 229 10 K 27 b 44 s 61 9 230 11 L 28 c 45 t 62 + 231 12 M 29 d 46 u 63 / 232 13 N 30 e 47 v 233 14 O 31 f 48 w (pad) = 234 15 P 32 g 49 x 235 16 Q 33 h 50 y 237 Special processing is performed if fewer than 24 bits are available 238 at the end of the data being encoded. A full encoding quantum is 239 always completed at the end of a quantity. When fewer than 24 input 240 bits are available in an input group, bits with value zero are added 241 (on the right) to form an integral number of 6-bit groups. Padding 242 at the end of the data is performed using the '=' character. Since 243 all base 64 input is an integral number of octets, only the following 244 cases can arise: 246 (1) the final quantum of encoding input is an integral multiple of 24 247 bits; here, the final unit of encoded output will be an integral 248 multiple of 4 characters with no "=" padding, 250 (2) the final quantum of encoding input is exactly 8 bits; here, the 251 final unit of encoded output will be two characters followed by two 252 "=" padding characters, or 254 (3) the final quantum of encoding input is exactly 16 bits; here, the 255 final unit of encoded output will be three characters followed by one 256 "=" padding character. 258 5. Base 64 Encoding With URL And Filename Safe Alphabet 260 The Base 64 encoding with an URL and filename safe alphabet has been 261 used in [11]. 263 An alternative alphabet has been suggested that used "~" as the 63rd 264 character. Since the "~" character has special meaning in some file 265 system environments, the encoding described in this section is 266 recommended instead. 268 This encoding may be referred to as "base64url". This encoding 269 should not be regarded as the same as the "base64" encoding, and 270 should not be referred to as only "base64". Unless made clear, 271 "base64" refer to the base 64 in the previous section. 273 This encoding is technically identical to the previous one, except 274 for the 62:nd and 63:rd alphabet character, as indicated in table 2. 276 Table 2: The "URL and Filename safe" Base 64 Alphabet 278 Value Encoding Value Encoding Value Encoding Value Encoding 279 0 A 17 R 34 i 51 z 280 1 B 18 S 35 j 52 0 281 2 C 19 T 36 k 53 1 282 3 D 20 U 37 l 54 2 283 4 E 21 V 38 m 55 3 284 5 F 22 W 39 n 56 4 285 6 G 23 X 40 o 57 5 286 7 H 24 Y 41 p 58 6 287 8 I 25 Z 42 q 59 7 288 9 J 26 a 43 r 60 8 289 10 K 27 b 44 s 61 9 290 11 L 28 c 45 t 62 - (minus) 291 12 M 29 d 46 u 63 _ 292 13 N 30 e 47 v (underline) 293 14 O 31 f 48 w 294 15 P 32 g 49 x 295 16 Q 33 h 50 y (pad) = 297 6. Base 32 Encoding 299 The following description of base 32 is derived from [10] (with 300 corrections). This encoding may be referred to as "base32". 302 The Base 32 encoding is designed to represent arbitrary sequences of 303 octets in a form that needs to be case insensitive but need not be 304 humanly readable. 306 A 33-character subset of US-ASCII is used, enabling 5 bits to be 307 represented per printable character. (The extra 33rd character, "=", 308 is used to signify a special processing function.) 310 The encoding process represents 40-bit groups of input bits as output 311 strings of 8 encoded characters. Proceeding from left to right, a 312 40-bit input group is formed by concatenating 5 8bit input groups. 313 These 40 bits are then treated as 8 concatenated 5-bit groups, each 314 of which is translated into a single character in the base 32 315 alphabet. When encoding a bit stream via the base 32 encoding, the 316 bit stream must be presumed to be ordered with the most-significant- 317 bit first. That is, the first bit in the stream will be the high- 318 order bit in the first 8bit byte, and the eighth bit will be the low- 319 order bit in the first 8bit byte, and so on. 321 Each 5-bit group is used as an index into an array of 32 printable 322 characters. The character referenced by the index is placed in the 323 output string. These characters, identified in Table 3, below, are 324 selected from US-ASCII digits and uppercase letters. 326 Table 3: The Base 32 Alphabet 328 Value Encoding Value Encoding Value Encoding Value Encoding 329 0 A 9 J 18 S 27 3 330 1 B 10 K 19 T 28 4 331 2 C 11 L 20 U 29 5 332 3 D 12 M 21 V 30 6 333 4 E 13 N 22 W 31 7 334 5 F 14 O 23 X 335 6 G 15 P 24 Y (pad) = 336 7 H 16 Q 25 Z 337 8 I 17 R 26 2 339 Special processing is performed if fewer than 40 bits are available 340 at the end of the data being encoded. A full encoding quantum is 341 always completed at the end of a body. When fewer than 40 input bits 342 are available in an input group, bits with value zero are added (on 343 the right) to form an integral number of 5-bit groups. Padding at 344 the end of the data is performed using the "=" character. Since all 345 base 32 input is an integral number of octets, only the following 346 cases can arise: 348 (1) the final quantum of encoding input is an integral multiple of 40 349 bits; here, the final unit of encoded output will be an integral 350 multiple of 8 characters with no "=" padding, 352 (2) the final quantum of encoding input is exactly 8 bits; here, the 353 final unit of encoded output will be two characters followed by six 354 "=" padding characters, 356 (3) the final quantum of encoding input is exactly 16 bits; here, the 357 final unit of encoded output will be four characters followed by four 358 "=" padding characters, 360 (4) the final quantum of encoding input is exactly 24 bits; here, the 361 final unit of encoded output will be five characters followed by 362 three "=" padding characters, or 364 (5) the final quantum of encoding input is exactly 32 bits; here, the 365 final unit of encoded output will be seven characters followed by one 366 "=" padding character. 368 7. Base 32 Encoding With Extended Hex Alphabet 370 The following description of base 32 is derived from [7]. This 371 encoding may be referred to as "base32hex". This encoding should not 372 be regarded as the same as the "base32" encoding, and should not be 373 referred to as only "base32". This encoding is used by, e.g., NSEC3 374 [9] 376 One property with this alphabet, that the base64 and base32 alphabet 377 lack, is that encoded data maintain its sort order when the encoded 378 data is compared bit-wise. 380 This encoding is identical to the previous one, except for the 381 alphabet. The new alphabet is found in table 4. 383 Table 4: The "Extended Hex" Base 32 Alphabet 385 Value Encoding Value Encoding Value Encoding Value Encoding 386 0 0 9 9 18 I 27 R 387 1 1 10 A 19 J 28 S 388 2 2 11 B 20 K 29 T 389 3 3 12 C 21 L 30 U 390 4 4 13 D 22 M 31 V 391 5 5 14 E 23 N 392 6 6 15 F 24 O (pad) = 393 7 7 16 G 25 P 394 8 8 17 H 26 Q 396 8. Base 16 Encoding 398 The following description is original but analogous to previous 399 descriptions. Essentially, Base 16 encoding is the standard case 400 insensitive hex encoding, and may be referred to as "base16" or 401 "hex". 403 A 16-character subset of US-ASCII is used, enabling 4 bits to be 404 represented per printable character. 406 The encoding process represents 8-bit groups (octets) of input bits 407 as output strings of 2 encoded characters. Proceeding from left to 408 right, a 8-bit input is taken from the input data. These 8 bits are 409 then treated as 2 concatenated 4-bit groups, each of which is 410 translated into a single character in the base 16 alphabet. 412 Each 4-bit group is used as an index into an array of 16 printable 413 characters. The character referenced by the index is placed in the 414 output string. 416 Table 5: The Base 16 Alphabet 418 Value Encoding Value Encoding Value Encoding Value Encoding 419 0 0 4 4 8 8 12 C 420 1 1 5 5 9 9 13 D 421 2 2 6 6 10 A 14 E 422 3 3 7 7 11 B 15 F 424 Unlike base 32 and base 64, no special padding is necessary since a 425 full code word is always available. 427 9. Illustrations And Examples 429 To translate between binary and a base encoding, the input is stored 430 in a structure and the output is extracted. The case for base 64 is 431 displayed in the following figure, borrowed from [5]. 433 +--first octet--+-second octet--+--third octet--+ 434 |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0| 435 +-----------+---+-------+-------+---+-----------+ 436 |5 4 3 2 1 0|5 4 3 2 1 0|5 4 3 2 1 0|5 4 3 2 1 0| 437 +--1.index--+--2.index--+--3.index--+--4.index--+ 439 The case for base 32 is shown in the following figure, borrowed from 440 [7]. Each successive character in a base-32 value represents 5 441 successive bits of the underlying octet sequence. Thus, each group 442 of 8 characters represents a sequence of 5 octets (40 bits). 444 1 2 3 445 01234567 89012345 67890123 45678901 23456789 446 +--------+--------+--------+--------+--------+ 447 |< 1 >< 2| >< 3 ><|.4 >< 5.|>< 6 ><.|7 >< 8 >| 448 +--------+--------+--------+--------+--------+ 449 <===> 8th character 450 <====> 7th character 451 <===> 6th character 452 <====> 5th character 453 <====> 4th character 454 <===> 3rd character 455 <====> 2nd character 456 <===> 1st character 458 The following example of Base64 data is from [5], with corrections. 460 Input data: 0x14fb9c03d97e 461 Hex: 1 4 f b 9 c | 0 3 d 9 7 e 462 8-bit: 00010100 11111011 10011100 | 00000011 11011001 01111110 463 6-bit: 000101 001111 101110 011100 | 000000 111101 100101 111110 464 Decimal: 5 15 46 28 0 61 37 62 465 Output: F P u c A 9 l + 467 Input data: 0x14fb9c03d9 468 Hex: 1 4 f b 9 c | 0 3 d 9 469 8-bit: 00010100 11111011 10011100 | 00000011 11011001 470 pad with 00 471 6-bit: 000101 001111 101110 011100 | 000000 111101 100100 472 Decimal: 5 15 46 28 0 61 36 473 pad with = 474 Output: F P u c A 9 k = 476 Input data: 0x14fb9c03 477 Hex: 1 4 f b 9 c | 0 3 478 8-bit: 00010100 11111011 10011100 | 00000011 479 pad with 0000 480 6-bit: 000101 001111 101110 011100 | 000000 110000 481 Decimal: 5 15 46 28 0 48 482 pad with = = 483 Output: F P u c A w = = 485 10. Test Vectors 487 BASE64("") = "" 489 BASE64("f") = "Zg==" 491 BASE64("fo") = "Zm8=" 493 BASE64("foo") = "Zm9v" 495 BASE64("foob") = "Zm9vYg==" 497 BASE64("fooba") = "Zm9vYmE=" 499 BASE64("foobar") = "Zm9vYmFy" 501 BASE32("") = "" 503 BASE32("f") = "MY======" 505 BASE32("fo") = "MZXQ====" 506 BASE32("foo") = "MZXW6===" 508 BASE32("foob") = "MZXW6YQ=" 510 BASE32("fooba") = "MZXW6YTB" 512 BASE32("foobar") = "MZXW6YTBOI======" 514 BASE32-HEX("") = "" 516 BASE32-HEX("f") = "CO======" 518 BASE32-HEX("fo") = "CPNG====" 520 BASE32-HEX("foo") = "CPNMU===" 522 BASE32-HEX("foob") = "CPNMUOG=" 524 BASE32-HEX("fooba") = "CPNMUOJ1" 526 BASE32-HEX("foobar") = "CPNMUOJ1E8======" 528 BASE16("") = "" 530 BASE16("f") = "66" 532 BASE16("fo") = "666F" 534 BASE16("foo") = "666F6F" 536 BASE16("foob") = "666F6F62" 538 BASE16("fooba") = "666F6F6261" 540 BASE16("foobar") = "666F6F626172" 542 11. ISO C99 Implementation Of Base64 544 Below is an ISO C99 implementation of Base64 encoding and decoding. 545 The code assume that the US-ASCII characters are encoding inside 546 'char' with values below 255, which holds for all POSIX platforms, 547 but should otherwise be portable. This code is not intended as a 548 normative specification of base64. 550 11.1. Prototypes: base64.h 552 /* base64.h -- Encode binary data using printable characters. 554 Copyright (C) 2004, 2005, 2006 Free Software Foundation, Inc. 555 Written by Simon Josefsson. 557 This program is free software; you can redistribute it 558 and/or modify it under the terms of the GNU Lesser 559 General Public License as published by the Free Software 560 Foundation; either version 2.1, or (at your option) any 561 later version. 563 This program is distributed in the hope that it will be 564 useful, but WITHOUT ANY WARRANTY; without even the 565 implied warranty of MERCHANTABILITY or FITNESS FOR A 566 PARTICULAR PURPOSE. See the GNU Lesser General Public 567 License for more details. 569 You should have received a copy of the GNU Lesser General 570 Public License along with this program; if not, write to 571 the Free Software Foundation, Inc., 51 Franklin Street, 572 Fifth Floor, Boston, MA 02110-1301, USA. */ 574 #ifndef BASE64_H 575 # define BASE64_H 577 /* Get size_t. */ 578 # include 580 /* Get bool. */ 581 # include 583 /* This uses that the expression (n+(k-1))/k means the 584 smallest integer >= n/k, i.e., the ceiling of n/k. */ 585 # define BASE64_LENGTH(inlen) ((((inlen) + 2) / 3) * 4) 587 extern bool isbase64 (char ch); 589 extern void base64_encode (const char *restrict in, 590 size_t inlen, 591 char *restrict out, 592 size_t outlen); 594 extern size_t base64_encode_alloc (const char *in, 595 size_t inlen, 596 char **out); 598 extern bool base64_decode (const char *restrict in, 599 size_t inlen, 600 char *restrict out, 601 size_t *outlen); 603 extern bool base64_decode_alloc (const char *in, 604 size_t inlen, 605 char **out, 606 size_t *outlen); 608 #endif /* BASE64_H */ 610 11.2. Implementation: base64.c 612 /* base64.c -- Encode binary data using printable characters. 613 Copyright (C) 1999, 2000, 2001, 2004, 2005, 2006 Free Software 614 Foundation, Inc. 616 This program is free software; you can redistribute it 617 and/or modify it under the terms of the GNU Lesser 618 General Public License as published by the Free Software 619 Foundation; either version 2.1, or (at your option) any 620 later version. 622 This program is distributed in the hope that it will be 623 useful, but WITHOUT ANY WARRANTY; without even the 624 implied warranty of MERCHANTABILITY or FITNESS FOR A 625 PARTICULAR PURPOSE. See the GNU Lesser General Public 626 License for more details. 628 You should have received a copy of the GNU Lesser General 629 Public License along with this program; if not, write to 630 the Free Software Foundation, Inc., 51 Franklin Street, 631 Fifth Floor, Boston, MA 02110-1301, USA. */ 633 /* Written by Simon Josefsson. Partially adapted from GNU 634 * MailUtils (mailbox/filter_trans.c, as of 2004-11-28). 635 * Improved by review from Paul Eggert, Bruno Haible, and 636 * Stepan Kasal. 637 * 638 * Be careful with error checking. Here is how you would 639 * typically use these functions: 640 * 641 * bool ok = base64_decode_alloc (in, inlen, &out, &outlen); 642 * if (!ok) 643 * FAIL: input was not valid base64 644 * if (out == NULL) 645 * FAIL: memory allocation error 646 * OK: data in OUT/OUTLEN 647 * 648 * size_t outlen = base64_encode_alloc (in, inlen, &out); 649 * if (out == NULL && outlen == 0 && inlen != 0) 650 * FAIL: input too long 651 * if (out == NULL) 652 * FAIL: memory allocation error 653 * OK: data in OUT/OUTLEN. 654 * 655 */ 657 /* Get prototype. */ 658 #include "base64.h" 660 /* Get malloc. */ 661 #include 663 /* Get UCHAR_MAX. */ 664 #include 666 /* C89 compliant way to cast 'char' to 'unsigned char'. */ 667 static inline unsigned char 668 to_uchar (char ch) 669 { 670 return ch; 671 } 673 /* Base64 encode IN array of size INLEN into OUT array of 674 size OUTLEN. If OUTLEN is less than 675 BASE64_LENGTH(INLEN), write as many bytes as possible. 676 If OUTLEN is larger than BASE64_LENGTH(INLEN), also zero 677 terminate the output buffer. */ 678 void 679 base64_encode (const char *restrict in, size_t inlen, 680 char *restrict out, size_t outlen) 681 { 682 static const char b64str[64] = 683 "ABCDEFGHIJKLMNOPQRSTUVWXYZ" 684 "abcdefghijklmnopqrstuvwxyz0123456789+/"; 686 while (inlen && outlen) 687 { 688 *out++ = b64str[to_uchar (in[0]) >> 2]; 689 if (!--outlen) 690 break; 691 *out++ = b64str[((to_uchar (in[0]) << 4) 692 + (--inlen ? to_uchar (in[1]) >> 4 : 0)) 693 & 0x3f]; 694 if (!--outlen) 695 break; 696 *out++ = 697 (inlen 698 ? b64str[((to_uchar (in[1]) << 2) 699 + (--inlen ? to_uchar (in[2]) >> 6 : 0)) 700 & 0x3f] 701 : '='); 702 if (!--outlen) 703 break; 704 *out++ = inlen ? b64str[to_uchar (in[2]) & 0x3f] : '='; 705 if (!--outlen) 706 break; 707 if (inlen) 708 inlen--; 709 if (inlen) 710 in += 3; 711 } 713 if (outlen) 714 *out = '\0'; 715 } 717 /* Allocate a buffer and store zero terminated base64 718 encoded data from array IN of size INLEN, returning 719 BASE64_LENGTH(INLEN), i.e., the length of the encoded 720 data, excluding the terminating zero. On return, the OUT 721 variable will hold a pointer to newly allocated memory 722 that must be deallocated by the caller. If output string 723 length would overflow, 0 is returned and OUT is set to 724 NULL. If memory allocation fail, OUT is set to NULL, and 725 the return value indicate length of the requested memory 726 block, i.e., BASE64_LENGTH(inlen) + 1. */ 727 size_t 728 base64_encode_alloc (const char *in, size_t inlen, char **out) 729 { 730 size_t outlen = 1 + BASE64_LENGTH (inlen); 732 /* Check for overflow in outlen computation. 733 * 734 * If there is no overflow, outlen >= inlen. 735 * 736 * If the operation (inlen + 2) overflows then it yields 737 * at most +1, so outlen is 0. 738 * 739 * If the multiplication overflows, we lose at least half 740 * of the correct value, so the result is < ((inlen + 741 * 2) / 3) * 2, which is less than (inlen + 2) * 0.66667, 742 * which is less than inlen as soon as (inlen > 4). 743 */ 744 if (inlen > outlen) 745 { 746 *out = NULL; 747 return 0; 748 } 750 *out = malloc (outlen); 751 if (*out) 752 base64_encode (in, inlen, *out, outlen); 754 return outlen - 1; 755 } 757 /* With this approach this file works independent of the 758 charset used (think EBCDIC). However, it does assume 759 that the characters in the Base64 alphabet (A-Za-z0-9+/) 760 are encoded in 0..255. POSIX 1003.1-2001 require that 761 char and unsigned char are 8-bit quantities, though, 762 taking care of that problem. But this may be a potential 763 problem on non-POSIX C99 platforms. */ 764 #define B64(x) \ 765 ((x) == 'A' ? 0 \ 766 : (x) == 'B' ? 1 \ 767 : (x) == 'C' ? 2 \ 768 : (x) == 'D' ? 3 \ 769 : (x) == 'E' ? 4 \ 770 : (x) == 'F' ? 5 \ 771 : (x) == 'G' ? 6 \ 772 : (x) == 'H' ? 7 \ 773 : (x) == 'I' ? 8 \ 774 : (x) == 'J' ? 9 \ 775 : (x) == 'K' ? 10 \ 776 : (x) == 'L' ? 11 \ 777 : (x) == 'M' ? 12 \ 778 : (x) == 'N' ? 13 \ 779 : (x) == 'O' ? 14 \ 780 : (x) == 'P' ? 15 \ 781 : (x) == 'Q' ? 16 \ 782 : (x) == 'R' ? 17 \ 783 : (x) == 'S' ? 18 \ 784 : (x) == 'T' ? 19 \ 785 : (x) == 'U' ? 20 \ 786 : (x) == 'V' ? 21 \ 787 : (x) == 'W' ? 22 \ 788 : (x) == 'X' ? 23 \ 789 : (x) == 'Y' ? 24 \ 790 : (x) == 'Z' ? 25 \ 791 : (x) == 'a' ? 26 \ 792 : (x) == 'b' ? 27 \ 793 : (x) == 'c' ? 28 \ 794 : (x) == 'd' ? 29 \ 795 : (x) == 'e' ? 30 \ 796 : (x) == 'f' ? 31 \ 797 : (x) == 'g' ? 32 \ 798 : (x) == 'h' ? 33 \ 799 : (x) == 'i' ? 34 \ 800 : (x) == 'j' ? 35 \ 801 : (x) == 'k' ? 36 \ 802 : (x) == 'l' ? 37 \ 803 : (x) == 'm' ? 38 \ 804 : (x) == 'n' ? 39 \ 805 : (x) == 'o' ? 40 \ 806 : (x) == 'p' ? 41 \ 807 : (x) == 'q' ? 42 \ 808 : (x) == 'r' ? 43 \ 809 : (x) == 's' ? 44 \ 810 : (x) == 't' ? 45 \ 811 : (x) == 'u' ? 46 \ 812 : (x) == 'v' ? 47 \ 813 : (x) == 'w' ? 48 \ 814 : (x) == 'x' ? 49 \ 815 : (x) == 'y' ? 50 \ 816 : (x) == 'z' ? 51 \ 817 : (x) == '0' ? 52 \ 818 : (x) == '1' ? 53 \ 819 : (x) == '2' ? 54 \ 820 : (x) == '3' ? 55 \ 821 : (x) == '4' ? 56 \ 822 : (x) == '5' ? 57 \ 823 : (x) == '6' ? 58 \ 824 : (x) == '7' ? 59 \ 825 : (x) == '8' ? 60 \ 826 : (x) == '9' ? 61 \ 827 : (x) == '+' ? 62 \ 828 : (x) == '/' ? 63 \ 829 : -1) 831 static const signed char b64[0x100] = { 832 B64 (0), B64 (1), B64 (2), B64 (3), 833 B64 (4), B64 (5), B64 (6), B64 (7), 834 B64 (8), B64 (9), B64 (10), B64 (11), 835 B64 (12), B64 (13), B64 (14), B64 (15), 836 B64 (16), B64 (17), B64 (18), B64 (19), 837 B64 (20), B64 (21), B64 (22), B64 (23), 838 B64 (24), B64 (25), B64 (26), B64 (27), 839 B64 (28), B64 (29), B64 (30), B64 (31), 840 B64 (32), B64 (33), B64 (34), B64 (35), 841 B64 (36), B64 (37), B64 (38), B64 (39), 842 B64 (40), B64 (41), B64 (42), B64 (43), 843 B64 (44), B64 (45), B64 (46), B64 (47), 844 B64 (48), B64 (49), B64 (50), B64 (51), 845 B64 (52), B64 (53), B64 (54), B64 (55), 846 B64 (56), B64 (57), B64 (58), B64 (59), 847 B64 (60), B64 (61), B64 (62), B64 (63), 848 B64 (64), B64 (65), B64 (66), B64 (67), 849 B64 (68), B64 (69), B64 (70), B64 (71), 850 B64 (72), B64 (73), B64 (74), B64 (75), 851 B64 (76), B64 (77), B64 (78), B64 (79), 852 B64 (80), B64 (81), B64 (82), B64 (83), 853 B64 (84), B64 (85), B64 (86), B64 (87), 854 B64 (88), B64 (89), B64 (90), B64 (91), 855 B64 (92), B64 (93), B64 (94), B64 (95), 856 B64 (96), B64 (97), B64 (98), B64 (99), 857 B64 (100), B64 (101), B64 (102), B64 (103), 858 B64 (104), B64 (105), B64 (106), B64 (107), 859 B64 (108), B64 (109), B64 (110), B64 (111), 860 B64 (112), B64 (113), B64 (114), B64 (115), 861 B64 (116), B64 (117), B64 (118), B64 (119), 862 B64 (120), B64 (121), B64 (122), B64 (123), 863 B64 (124), B64 (125), B64 (126), B64 (127), 864 B64 (128), B64 (129), B64 (130), B64 (131), 865 B64 (132), B64 (133), B64 (134), B64 (135), 866 B64 (136), B64 (137), B64 (138), B64 (139), 867 B64 (140), B64 (141), B64 (142), B64 (143), 868 B64 (144), B64 (145), B64 (146), B64 (147), 869 B64 (148), B64 (149), B64 (150), B64 (151), 870 B64 (152), B64 (153), B64 (154), B64 (155), 871 B64 (156), B64 (157), B64 (158), B64 (159), 872 B64 (160), B64 (161), B64 (162), B64 (163), 873 B64 (164), B64 (165), B64 (166), B64 (167), 874 B64 (168), B64 (169), B64 (170), B64 (171), 875 B64 (172), B64 (173), B64 (174), B64 (175), 876 B64 (176), B64 (177), B64 (178), B64 (179), 877 B64 (180), B64 (181), B64 (182), B64 (183), 878 B64 (184), B64 (185), B64 (186), B64 (187), 879 B64 (188), B64 (189), B64 (190), B64 (191), 880 B64 (192), B64 (193), B64 (194), B64 (195), 881 B64 (196), B64 (197), B64 (198), B64 (199), 882 B64 (200), B64 (201), B64 (202), B64 (203), 883 B64 (204), B64 (205), B64 (206), B64 (207), 884 B64 (208), B64 (209), B64 (210), B64 (211), 885 B64 (212), B64 (213), B64 (214), B64 (215), 886 B64 (216), B64 (217), B64 (218), B64 (219), 887 B64 (220), B64 (221), B64 (222), B64 (223), 888 B64 (224), B64 (225), B64 (226), B64 (227), 889 B64 (228), B64 (229), B64 (230), B64 (231), 890 B64 (232), B64 (233), B64 (234), B64 (235), 891 B64 (236), B64 (237), B64 (238), B64 (239), 892 B64 (240), B64 (241), B64 (242), B64 (243), 893 B64 (244), B64 (245), B64 (246), B64 (247), 894 B64 (248), B64 (249), B64 (250), B64 (251), 895 B64 (252), B64 (253), B64 (254), B64 (255) 896 }; 898 #if UCHAR_MAX == 255 899 # define uchar_in_range(c) true 900 #else 901 # define uchar_in_range(c) ((c) <= 255) 902 #endif 904 bool 905 isbase64 (char ch) 906 { 907 return uchar_in_range (to_uchar (ch)) && 0 <= b64[to_uchar (ch)]; 908 } 910 /* Decode base64 encoded input array IN of length INLEN to 911 output array OUT that can hold *OUTLEN bytes. Return 912 true if decoding was successful, i.e. if the input was 913 valid base64 data, false otherwise. If *OUTLEN is too 914 small, as many bytes as possible will be written to OUT. 915 On return, *OUTLEN holds the length of decoded bytes in 916 OUT. Note that as soon as any non-alphabet characters 917 are encountered, decoding is stopped and false is 918 returned. This means that, when applicable, you must 919 remove any line terminators that is part of the data 920 stream before calling this function. */ 921 bool 922 base64_decode (const char *restrict in, size_t inlen, 923 char *restrict out, size_t *outlen) 924 { 925 size_t outleft = *outlen; 927 while (inlen >= 2) 928 { 929 if (!isbase64 (in[0]) || !isbase64 (in[1])) 930 break; 932 if (outleft) 933 { 934 *out++ = ((b64[to_uchar (in[0])] << 2) 935 | (b64[to_uchar (in[1])] >> 4)); 936 outleft--; 937 } 939 if (inlen == 2) 940 break; 942 if (in[2] == '=') 943 { 944 if (inlen != 4) 945 break; 947 if (in[3] != '=') 948 break; 950 } 951 else 952 { 953 if (!isbase64 (in[2])) 954 break; 956 if (outleft) 957 { 958 *out++ = (((b64[to_uchar (in[1])] << 4) & 0xf0) 959 | (b64[to_uchar (in[2])] >> 2)); 960 outleft--; 961 } 963 if (inlen == 3) 964 break; 966 if (in[3] == '=') 967 { 968 if (inlen != 4) 969 break; 970 } 971 else 972 { 973 if (!isbase64 (in[3])) 974 break; 976 if (outleft) 977 { 978 *out++ = (((b64[to_uchar (in[2])] << 6) & 0xc0) 979 | b64[to_uchar (in[3])]); 980 outleft--; 981 } 982 } 983 } 985 in += 4; 986 inlen -= 4; 988 } 990 *outlen -= outleft; 992 if (inlen != 0) 993 return false; 995 return true; 996 } 998 /* Allocate an output buffer in *OUT, and decode the base64 999 encoded data stored in IN of size INLEN to the *OUT 1000 buffer. On return, the size of the decoded data is 1001 stored in *OUTLEN. OUTLEN may be NULL, if the caller is 1002 not interested in the decoded length. *OUT may be NULL 1003 to indicate an out of memory error, in which case *OUTLEN 1004 contain the size of the memory block needed. The 1005 function return true on successful decoding and memory 1006 allocation errors. (Use the *OUT and *OUTLEN parameters 1007 to differentiate between successful decoding and memory 1008 error.) The function return false if the input was 1009 invalid, in which case *OUT is NULL and *OUTLEN is 1010 undefined. */ 1011 bool 1012 base64_decode_alloc (const char *in, size_t inlen, char **out, 1013 size_t *outlen) 1014 { 1015 /* This may allocate a few bytes too much, depending on 1016 input, but it's not worth the extra CPU time to compute 1017 the exact amount. The exact amount is 3 * inlen / 4, 1018 minus 1 if the input ends with "=" and minus another 1 1019 if the input ends with "==". Dividing before 1020 multiplying avoids the possibility of overflow. */ 1021 size_t needlen = 3 * (inlen / 4) + 2; 1023 *out = malloc (needlen); 1024 if (!*out) 1025 return true; 1027 if (!base64_decode (in, inlen, *out, &needlen)) 1028 { 1029 free (*out); 1030 *out = NULL; 1031 return false; 1032 } 1034 if (outlen) 1035 *outlen = needlen; 1037 return true; 1038 } 1040 12. Security Considerations 1042 When implementing Base encoding and decoding, care should be taken 1043 not to introduce vulnerabilities to buffer overflow attacks, or other 1044 attacks on the implementation. A decoder should not break on invalid 1045 input including, e.g., embedded NUL characters (ASCII 0). 1047 If non-alphabet characters are ignored, instead of causing rejection 1048 of the entire encoding (as recommended), a covert channel that can be 1049 used to "leak" information is made possible. The implications of 1050 this should be understood in applications that do not follow the 1051 recommended practice. Similarly, when the base 16 and base 32 1052 alphabets are handled case insensitively, alteration of case can be 1053 used to leak information. 1055 Base encoding visually hides otherwise easily recognized information, 1056 such as passwords, but does not provide any computational 1057 confidentiality. This has been known to cause security incidents 1058 when, e.g., a user reports details of a network protocol exchange 1059 (perhaps to illustrate some other problem) and accidentally reveals 1060 the password because she is unaware that the base encoding does not 1061 protect the password. 1063 Base encoding adds no entropy to the plaintext, but it does increase 1064 the amount of plaintext available and provides a signature for 1065 cryptanalysis in the form of a characteristic probability 1066 distribution. 1068 13. Changes Since RFC 3548 1070 Added the "base32 extended hex alphabet", needed to preserve sort 1071 order of encoded data. 1073 Reference IMAP for the special Base64 encoding used there. 1075 Fix the example copied from RFC 2440. 1077 Add security consideration about providing a signature for 1078 cryptoanalysis. 1080 Add test vectors and C99 implementation. 1082 Typo fixes. 1084 14. Acknowledgements 1086 Several people offered comments and/or suggestions, including John E. 1087 Hadstate, Tony Hansen, Gordon Mohr, John Myers, Chris Newman and 1088 Andrew Sieber. Text used in this document are based on earlier RFCs 1089 describing specific uses of various base encodings. The author 1090 acknowledges the RSA Laboratories for supporting the work that led to 1091 this document. 1093 This revised version is based in parts on comments and/or suggestions 1094 made by Roy Arends, Eric Blake, Elwyn Davies, Ted Hardie, Per Hygum, 1095 Jelte Jansen, Clement Kent, Paul Kwiatkowski, and Ben Laurie. 1097 15. Copying Conditions 1099 Copyright (c) 2000-2006 Simon Josefsson 1101 Regarding the abstract and section 1, 3, 8, 10, 12, 13, and 14 of 1102 this document, that were written by Simon Josefsson ("the author", 1103 for the remainder of this section), the author makes no guarantees 1104 and is not responsible for any damage resulting from its use. The 1105 author grants irrevocable permission to anyone to use, modify, and 1106 distribute it in any way that does not diminish the rights of anyone 1107 else to use, modify, and distribute it, provided that redistributed 1108 derivative works do not contain misleading author or version 1109 information. Derivative works need not be licensed under similar 1110 terms. 1112 16. References 1114 16.1. Normative References 1116 [1] Cerf, V., "ASCII format for network interchange", RFC 20, 1117 October 1969. 1119 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1120 Levels", BCP 14, RFC 2119, March 1997. 1122 16.2. Informative References 1124 [3] Linn, J., "Privacy Enhancement for Internet Electronic Mail: 1125 Part I: Message Encryption and Authentication Procedures", 1126 RFC 1421, February 1993. 1128 [4] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1129 Extensions (MIME) Part One: Format of Internet Message Bodies", 1130 RFC 2045, November 1996. 1132 [5] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer, 1133 "OpenPGP Message Format", RFC 2440, November 1998. 1135 [6] Eastlake, D., "Domain Name System Security Extensions", 1136 RFC 2535, March 1999. 1138 [7] Klyne, G. and L. Masinter, "Identifying Composite Media 1139 Features", RFC 2938, September 2000. 1141 [8] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 1142 4rev1", RFC 3501, March 2003. 1144 [9] Laurie, B., "DNSSEC Hash Authenticated Denial of Existence", 1145 draft-ietf-dnsext-nsec3-04 (work in progress), March 2006. 1147 [10] Myers, J., "SASL GSSAPI mechanisms", Work in 1148 progress draft-ietf-cat-sasl-gssapi-01, May 2000. 1150 [11] Wilcox-O'Hearn, B., "Post to P2P-hackers mailing list", World 1151 Wide Web http://zgp.org/pipermail/p2p-hackers/2001-September/ 1152 000315.html, September 2001. 1154 Author's Address 1156 Simon Josefsson 1157 SJD 1159 Email: simon@josefsson.org 1161 Intellectual Property Statement 1163 The IETF takes no position regarding the validity or scope of any 1164 Intellectual Property Rights or other rights that might be claimed to 1165 pertain to the implementation or use of the technology described in 1166 this document or the extent to which any license under such rights 1167 might or might not be available; nor does it represent that it has 1168 made any independent effort to identify any such rights. Information 1169 on the procedures with respect to rights in RFC documents can be 1170 found in BCP 78 and BCP 79. 1172 Copies of IPR disclosures made to the IETF Secretariat and any 1173 assurances of licenses to be made available, or the result of an 1174 attempt made to obtain a general license or permission for the use of 1175 such proprietary rights by implementers or users of this 1176 specification can be obtained from the IETF on-line IPR repository at 1177 http://www.ietf.org/ipr. 1179 The IETF invites any interested party to bring to its attention any 1180 copyrights, patents or patent applications, or other proprietary 1181 rights that may cover technology that may be required to implement 1182 this standard. Please address the information to the IETF at 1183 ietf-ipr@ietf.org. 1185 Disclaimer of Validity 1187 This document and the information contained herein are provided on an 1188 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1189 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1190 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1191 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1192 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1193 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1195 Copyright Statement 1197 Copyright (C) The Internet Society (2006). This document is subject 1198 to the rights, licenses and restrictions contained in BCP 78, and 1199 except as set forth therein, the authors retain all their rights. 1201 Acknowledgment 1203 Funding for the RFC Editor function is currently provided by the 1204 Internet Society.