idnits 2.17.00 (12 Aug 2021) /tmp/idnits34793/draft-josefsson-base-encoding-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. == 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 Introduction section. ** 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 document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([3]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 4, 2001) is 7686 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '2' is defined on line 306, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1113 (ref. '1') (Obsoleted by RFC 1421) ** Downref: Normative reference to an Informational RFC: RFC 1924 (ref. '2') ** Obsolete normative reference: RFC 2535 (ref. '5') (Obsoleted by RFC 4033, RFC 4034, RFC 4035) == Outdated reference: A later version (-05) exists of draft-ietf-cat-sasl-gssapi-01 -- Possible downref: Normative reference to a draft: ref. '6' Summary: 9 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Josefsson (editor) 3 Internet-Draft Extundo 4 Expires: November 2, 2001 May 4, 2001 6 Base Encodings 7 draft-josefsson-base-encoding-02.txt 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as 17 Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other documents 21 at any time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 This Internet-Draft will expire on November 2, 2001. 32 Distribution of this document is unlimited. Comments and 33 suggestions on this document are encouraged. 35 Copyright Notice 37 Copyright (C) The Internet Society (2001). All Rights Reserved. 39 Abstract 41 This draft contain descriptions of the commonly used base 16, base 42 32, and base 64 encoding schemes. It also discusses the use of 43 line-feeds in encoded data, use of padding in encoded data, use of 44 non-alphabet characters in encoded data, and use of different 45 encoding alphabets (where applicable). 47 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 48 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 49 document are to be interpreted as described in RFC 2119 [3]. 51 Table of Contents 53 1. Implementation variances . . . . . . . . . . . . . . . . . . . 3 54 1.1 Line feeds in encoded data . . . . . . . . . . . . . . . . . . 3 55 1.2 Padding of encoded data . . . . . . . . . . . . . . . . . . . 3 56 1.3 Interpretation of non-alphabet characters in encoded data . . 3 57 2. Base 64 Encoding . . . . . . . . . . . . . . . . . . . . . . . 4 58 3. Base 32 Encoding . . . . . . . . . . . . . . . . . . . . . . . 6 59 4. Base 16 Encoding . . . . . . . . . . . . . . . . . . . . . . . 8 60 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 61 References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 62 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 10 63 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 11 65 1. Implementation variances 67 Base encodings have historically been implemented with some minor 68 variances. This section's purpose is to describe these variances, 69 and to mandate a default behaviour, to reduce the possibility for 70 ambiguity in other documents using base encodings. 72 1.1 Line feeds in encoded data 74 RFC 2045 [4] is often used as a reference for base64 encoding. 75 However, RFC2045 does not define "base64" per se, but rather a 76 "base64 Content-Transfer-Encoding" for use within MIME. RFC 2045 77 enforces a limit on line length of base64 encode data to 76 78 characters. 80 Implementation of specifications using this document as reference 81 for base encodings MUST NOT add line feeds to the encoded data, 82 unless explicitely stated and handled otherwise in said 83 specifications. 85 1.2 Padding of encoded data 87 In some circumstances, the use of padding ("=") in base encoded data 88 is not required nor used. 90 Implementation of specifications using this document as reference 91 for base encodings MUST do proper padding to the encoded data, 92 unless explicitely stated and handled otherwise in said 93 specifications. 95 1.3 Interpretation of non-alphabet characters in encoded data 97 Base encodings use a specific, reduced, alphabet to encode binary 98 data. Non base alphabet characters may exist within base encoded 99 data, caused by data corruption or by design. 101 Implementations of specifications using this document as reference 102 for base encodings MUST ignore characters outside the base encoding 103 alphabet when interpreting base encoded data (``be liberal in what 104 you accept''), unless explicitely stated and handled otherwise in 105 said specifications. 107 (Note that this means, e.g. CRLF-padding after 76 characters 108 constitue "non alphabet characters", and should simply be ignored. 109 Also, the pad character, "=", should not be regarded as part of the 110 base alphabet until the end of the string.) 112 2. Base 64 Encoding 114 The following description of base64 is due to [1], [4] and [5]. 116 A 65-character subset of US-ASCII is used, enabling 6 bits to be 117 represented per printable character. (The extra 65th character, "=", 118 is used to signify a special processing function.) 120 The encoding process represents 24-bit groups of input bits as 121 output strings of 4 encoded characters. Proceeding from left to 122 right, a 24-bit input group is formed by concatenating 3 8-bit input 123 groups. These 24 bits are then treated as 4 concatenated 6-bit 124 groups, each of which is translated into a single digit in the base 125 64 alphabet. 127 Each 6-bit group is used as an index into an array of 64 printable 128 characters. The character referenced by the index is placed in the 129 output string. 131 Table 1: The Base 64 Alphabet 133 Value Encoding Value Encoding Value Encoding Value Encoding 134 0 A 17 R 34 i 51 z 135 1 B 18 S 35 j 52 0 136 2 C 19 T 36 k 53 1 137 3 D 20 U 37 l 54 2 138 4 E 21 V 38 m 55 3 139 5 F 22 W 39 n 56 4 140 6 G 23 X 40 o 57 5 141 7 H 24 Y 41 p 58 6 142 8 I 25 Z 42 q 59 7 143 9 J 26 a 43 r 60 8 144 10 K 27 b 44 s 61 9 145 11 L 28 c 45 t 62 + 146 12 M 29 d 46 u 63 / 147 13 N 30 e 47 v 148 14 O 31 f 48 w (pad) = 149 15 P 32 g 49 x 150 16 Q 33 h 50 y 152 Special processing is performed if fewer than 24 bits are available 153 at the end of the data being encoded. A full encoding quantum is 154 always completed at the end of a quantity. When fewer than 24 input 155 bits are available in an input group, zero bits are added (on the 156 right) to form an integral number of 6-bit groups. Padding at the 157 end of the data is performed using the '=' character. Since all 158 base 64 input is an integral number of octets, only the following 159 cases can arise: 161 (1) the final quantum of encoding input is an integral multiple of 162 24 bits; here, the final unit of encoded output will be an integral 163 multiple of 4 characters with no "=" padding, 165 (2) the final quantum of encoding input is exactly 8 bits; here, the 166 final unit of encoded output will be two characters followed by two 167 "=" padding characters, or 169 (3) the final quantum of encoding input is exactly 16 bits; here, 170 the final unit of encoded output will be three characters followed 171 by one "=" padding character. 173 3. Base 32 Encoding 175 The following description of base32 is due to [6] (the padding 176 section has been corrected though). 178 The Base32 encoding is designed to represent arbitrary sequences of 179 octets in a form that needs to be case insensitive but need not be 180 humanly readable. 182 A 33-character subset of US-ASCII is used, enabling 5 bits to be 183 represented per printable character. (The extra 33rd character, "=", 184 is used to signify a special processing function.) 186 The encoding process represents 40-bit groups of input bits as 187 output strings of 8 encoded characters. Proceeding from left to 188 right, a 40-bit input group is formed by concatenating 5 8bit input 189 groups. These 40 bits are then treated as 8 concatenated 5-bit 190 groups, each of which is translated into a single digit in the 191 base32 alphabet. When encoding a bit stream via the base32 192 encoding, the bit stream must be presumed to be ordered with the 193 most-significant-bit first. That is, the first bit in the stream 194 will be the high-order bit in the first 8bit byte, and the eighth 195 bit will be the low-order bit in the first 8bit byte, and so on. 197 Each 5-bit group is used as an index into an array of 32 printable 198 characters. The character referenced by the index is placed in the 199 output string. These characters, identified in Table 2, below, are 200 selected from US-ASCII digits and uppercase letters. 202 Table 2: The Base32 Alphabet 204 Value Encoding Value Encoding Value Encoding Value Encoding 205 0 A 9 J 18 S 27 3 206 1 B 10 K 19 T 28 4 207 2 C 11 L 20 U 29 5 208 3 D 12 M 21 V 30 6 209 4 E 13 N 22 W 31 7 210 5 F 14 O 23 X 211 6 G 15 P 24 Y (pad) = 212 7 H 16 Q 25 Z 213 8 I 17 R 26 2 215 Special processing is performed if fewer than 40 bits are available 216 at the end of the data being encoded. A full encoding quantum is 217 always completed at the end of a body. When fewer than 40 input 218 bits are available in an input group, zero bits are added (on the 219 right) to form an integral number of 5-bit groups. Padding at the 220 end of the data is performed using the "=" character. Since all 221 base32 input is an integral number of octets, only the following 222 cases can arise: 224 (1) the final quantum of encoding input is an integral multiple of 225 40 bits; here, the final unit of encoded output will be an integral 226 multiple of 8 characters with no "=" padding, 228 (2) the final quantum of encoding input is exactly 8 bits; here, the 229 final unit of encoded output will be two characters followed by six 230 "=" padding characters, 232 (3) the final quantum of encoding input is exactly 16 bits; here, 233 the final unit of encoded output will be four characters followed by 234 four "=" padding characters, 236 (4) the final quantum of encoding input is exactly 24 bits; here, 237 the final unit of encoded output will be five characters followed by 238 three "=" padding characters, or 240 (5) the final quantum of encoding input is exactly 32 bits; here, 241 the final unit of encoded output will be seven characters followed 242 by one "=" padding character. 244 Because it is used only for padding at the end of the data, the 245 occurrence of any "=" characters may be taken as evidence that the 246 end of the data has been reached (without truncation in transit). 247 No such assurance is possible, however, when the number of octets 248 transmitted was a multiple of three and no "=" characters are 249 present. 251 4. Base 16 Encoding 253 The following description is original but analogous to previous 254 descriptions. 256 A 16-character subset of US-ASCII is used, enabling 4 bits to be 257 represented per printable character. 259 The encoding process represents 8-bit groups (octets) of input bits 260 as output strings of 2 encoded characters. Proceeding from left to 261 right, a 8-bit input is taken from the input data. These 8 bits are 262 then treated as 2 concatenated 4-bit groups, each of which is 263 translated into a single digit in the base 16 alphabet. 265 Each 4-bit group is used as an index into an array of 16 printable 266 characters. The character referenced by the index is placed in the 267 output string. 269 This draft describe two alphabets used with Base 16 encoding, the 270 first is considered to be more common. A variation of the first, 271 "lowercase hex format", uses lower case characters for values 10-15. 273 Table 3: The "Hex" Base 16 Alphabet 275 Value Encoding Value Encoding Value Encoding Value Encoding 276 0 0 4 4 8 8 12 C 277 1 1 5 5 9 9 13 D 278 2 2 6 6 10 A 14 E 279 3 3 7 7 11 B 15 F 281 Table 4: The Canonical Base 16 Alphabet 283 Value Encoding Value Encoding Value Encoding Value Encoding 284 0 A 4 E 8 I 12 M 285 1 B 5 F 9 J 13 N 286 2 C 6 G 10 K 14 O 287 3 D 7 H 11 L 15 P 289 Unlike base32 and base64, no special padding is necessery since a 290 full code word is always available. 292 5. Security Considerations 294 This draft does not discuss security. 296 Acknowledgement 298 I'd like to thank Tony Hansen for comments on the draft. 300 References 302 [1] Linn, J., "Privacy Enhancement for Internet Electronic Mail: 303 Part I -- Message Encipherment and Authentication Procedures", 304 RFC 1113, August 1989. 306 [2] Elz, R., "A Compact Representation of IPv6 Addresses", RFC 307 1924, April 1996. 309 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 310 Levels", RFC 2119, March 1997. 312 [4] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 313 Extensions (MIME) Part One: Format of Internet Message Bodies", 314 RFC 2045, November 1996. 316 [5] Eastlake, D., "Domain Name System Security Extensions", RFC 317 2535, March 1999. 319 [6] Myers, J., "SASL GSSAPI mechanisms", draft 320 draft-ietf-cat-sasl-gssapi-01, May 2000. 322 Author's Address 324 Simon Josefsson 325 Extundo 326 Drottningholmsv„gen 70 327 Stockholm 112 42 328 Sweden 330 Phone: +46 8 6190422 331 EMail: simon@josefsson.org 333 Full Copyright Statement 335 Copyright (C) The Internet Society (2001). All Rights Reserved. 337 This document and translations of it may be copied and furnished to 338 others, and derivative works that comment on or otherwise explain it 339 or assist in its implementation may be prepared, copied, published 340 and distributed, in whole or in part, without restriction of any 341 kind, provided that the above copyright notice and this paragraph 342 are included on all such copies and derivative works. However, this 343 document itself may not be modified in any way, such as by removing 344 the copyright notice or references to the Internet Society or other 345 Internet organizations, except as needed for the purpose of 346 developing Internet standards in which case the procedures for 347 copyrights defined in the Internet Standards process must be 348 followed, or as required to translate it into languages other than 349 English. 351 The limited permissions granted above are perpetual and will not be 352 revoked by the Internet Society or its successors or assigns. 354 This document and the information contained herein is provided on an 355 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 356 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 357 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 358 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 359 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.