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