idnits 2.17.00 (12 Aug 2021) /tmp/idnits35015/draft-josefsson-base-encoding-00.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. 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 (August 22, 2000) is 7941 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) -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S.A. Josefsson (editor) 3 Internet-Draft Extundo 4 Expires: February 20, 2001 August 22, 2000 6 Base 64, 32 and 16 Encodings 7 draft-josefsson-base-encoding-00.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 February 20, 2001. 32 Copyright Notice 34 Copyright (C) The Internet Society (2000). All Rights Reserved. 36 Abstract 38 This draft serve as a canonical collection of base 16, base 32 and 39 base 64 encoding descriptions. 41 Table of Contents 43 1. Base 64 Encoding . . . . . . . . . . . . . . . . . . . . . . . 3 44 2. Base 32 Encoding . . . . . . . . . . . . . . . . . . . . . . . 5 45 3. Base 16 Encoding . . . . . . . . . . . . . . . . . . . . . . . 7 46 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 47 References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 48 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 9 49 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 10 51 1. Base 64 Encoding 53 The following description of base64 is due to [1] and [2]. 55 A 65-character subset of US-ASCII is used, enabling 6 bits to be 56 represented per printable character. (The extra 65th character, "=", 57 is used to signify a special processing function.) 59 The encoding process represents 24-bit groups of input bits as 60 output strings of 4 encoded characters. Proceeding from left to 61 right, a 24-bit input group is formed by concatenating 3 8-bit input 62 groups. These 24 bits are then treated as 4 concatenated 6-bit 63 groups, each of which is translated into a single digit in the base 64 64 alphabet. 66 Each 6-bit group is used as an index into an array of 64 printable 67 characters. The character referenced by the index is placed in the 68 output string. 70 Table 1: The Base 64 Alphabet 72 Value Encoding Value Encoding Value Encoding Value Encoding 73 0 A 17 R 34 i 51 z 74 1 B 18 S 35 j 52 0 75 2 C 19 T 36 k 53 1 76 3 D 20 U 37 l 54 2 77 4 E 21 V 38 m 55 3 78 5 F 22 W 39 n 56 4 79 6 G 23 X 40 o 57 5 80 7 H 24 Y 41 p 58 6 81 8 I 25 Z 42 q 59 7 82 9 J 26 a 43 r 60 8 83 10 K 27 b 44 s 61 9 84 11 L 28 c 45 t 62 + 85 12 M 29 d 46 u 63 / 86 13 N 30 e 47 v 87 14 O 31 f 48 w (pad) = 88 15 P 32 g 49 x 89 16 Q 33 h 50 y 91 Special processing is performed if fewer than 24 bits are available 92 at the end of the data being encoded. A full encoding quantum is 93 always completed at the end of a quantity. When fewer than 24 input 94 bits are available in an input group, zero bits are added (on the 95 right) to form an integral number of 6-bit groups. Padding at the 96 end of the data is performed using the '=' character. Since all 97 base 64 input is an integral number of octets, only the following 98 cases can arise: 100 (1) the final quantum of encoding input is an integral multiple of 101 24 bits; here, the final unit of encoded output will be an integral 102 multiple of 4 characters with no "=" padding, 104 (2) the final quantum of encoding input is exactly 8 bits; here, the 105 final unit of encoded output will be two characters followed by two 106 "=" padding characters, or 108 (3) the final quantum of encoding input is exactly 16 bits; here, 109 the final unit of encoded output will be three characters followed 110 by one "=" padding character. 112 Any characters outside of the base64 alphabet are to be ignored in 113 base64-encoded data. 115 2. Base 32 Encoding 117 The following description of base32 is due to [3], the padding 118 section was updated to fix two typos. 120 The Base32 encoding is designed to represent arbitrary sequences of 121 octets in a form that needs to be case insensitive but need not be 122 humanly readable. 124 A 33-character subset of US-ASCII is used, enabling 5 bits to be 125 represented per printable character. (The extra 33rd character, "=", 126 is used to signify a special processing function.) 128 The encoding process represents 40-bit groups of input bits as 129 output strings of 8 encoded characters. Proceeding from left to 130 right, a 40-bit input group is formed by concatenating 5 8bit input 131 groups. These 40 bits are then treated as 8 concatenated 5-bit 132 groups, each of which is translated into a single digit in the 133 base32 alphabet. When encoding a bit stream via the base32 134 encoding, the bit stream must be presumed to be ordered with the 135 most-significant-bit first. That is, the first bit in the stream 136 will be the high-order bit in the first 8bit byte, and the eighth 137 bit will be the low-order bit in the first 8bit byte, and so on. 139 Each 5-bit group is used as an index into an array of 32 printable 140 characters. The character referenced by the index is placed in the 141 output string. These characters, identified in Table 2, below, are 142 selected from US-ASCII digits and uppercase letters. 144 Table 2: The Base32 Alphabet 146 Value Encoding Value Encoding Value Encoding Value Encoding 147 0 A 9 J 18 S 27 3 148 1 B 10 K 19 T 28 4 149 2 C 11 L 20 U 29 5 150 3 D 12 M 21 V 30 6 151 4 E 13 N 22 W 31 7 152 5 F 14 O 23 X 153 6 G 15 P 24 Y (pad) = 154 7 H 16 Q 25 Z 155 8 I 17 R 26 2 157 Special processing is performed if fewer than 40 bits are available 158 at the end of the data being encoded. A full encoding quantum is 159 always completed at the end of a body. When fewer than 40 input bits 160 are available in an input group, zero bits are added (on the right) 161 to form an integral number of 5-bit groups. Padding at the end of 162 the data is performed using the "=" character. Since all base32 163 input is an integral number of octets, only the following cases can 164 arise: 166 (1) the final quantum of encoding input is an integral multiple of 167 40 bits; here, the final unit of encoded output will be an integral 168 multiple of 8 characters with no "=" padding, 170 (2) the final quantum of encoding input is exactly 8 bits; here, the 171 final unit of encoded output will be two characters followed by six 172 "=" padding characters, 174 (3) the final quantum of encoding input is exactly 16 bits; here, 175 the final unit of encoded output will be four characters followed by 176 four "=" padding characters, 178 (4) the final quantum of encoding input is exactly 24 bits; here, 179 the final unit of encoded output will be five characters followed by 180 three "=" padding characters, or 182 (5) the final quantum of encoding input is exactly 32 bits; here, 183 the final unit of encoded output will be seven characters followed 184 by one "=" padding character. 186 Because it is used only for padding at the end of the data, the 187 occurrence of any "=" characters may be taken as evidence that the 188 end of the data has been reached (without truncation in transit). 189 No such assurance is possible, however, when the number of octets 190 transmitted was a multiple of three and no "=" characters are 191 present. 193 Any characters outside of the base32 alphabet are to be ignored in 194 base32-encoded data. 196 3. Base 16 Encoding 198 The following description is original but analog to previous 199 descriptions. 201 A 16-character subset of US-ASCII is used, enabling 4 bits to be 202 represented per printable character. 204 The encoding process represents 8-bit groups (octets) of input bits 205 as output strings of 2 encoded characters. Proceeding from left to 206 right, a 8-bit input is taken from the input data. These 8 bits are 207 then treated as 2 concatenated 4-bit groups, each of which is 208 translated into a single digit in the base 16 alphabet. 210 Each 4-bit group is used as an index into an array of 16 printable 211 characters. The character referenced by the index is placed in the 212 output string. 214 Table 3: The Base 16 Alphabet 216 Value Encoding Value Encoding Value Encoding Value Encoding 217 0 A 5 F 10 K 15 P 218 1 B 6 G 11 L 16 Q 219 2 C 7 H 12 M 220 3 D 8 I 13 N 221 4 E 9 J 14 O 223 Unlike base32 and base64, no special padding is necessery since a 224 full code words are always available. 226 Any characters outside of the base32 alphabet are to be ignored in 227 base32-encoded data. 229 4. Security Considerations 231 This draft does not discuss security. 233 References 235 [1] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 236 Extensions (MIME) Part One: Format of Internet Message Bodies", 237 November 1996. 239 [2] Eastlake, D., "Domain Name System Security Extensions", March 240 1999. 242 [3] Myers, J., "SASL GSSAPI mechanisms", May 2000. 244 Author's Address 246 Simon Josefsson 247 Extundo 248 Drottningholmsvägen 70 249 Stockholm 112 42 250 Sweden 252 Phone: +46 8 6190422 253 EMail: simon@josefsson.org 255 Full Copyright Statement 257 Copyright (C) The Internet Society (2000). All Rights Reserved. 259 This document and translations of it may be copied and furnished to 260 others, and derivative works that comment on or otherwise explain it 261 or assist in its implementation may be prepared, copied, published 262 and distributed, in whole or in part, without restriction of any 263 kind, provided that the above copyright notice and this paragraph 264 are included on all such copies and derivative works. However, this 265 document itself may not be modified in any way, such as by removing 266 the copyright notice or references to the Internet Society or other 267 Internet organizations, except as needed for the purpose of 268 developing Internet standards in which case the procedures for 269 copyrights defined in the Internet Standards process must be 270 followed, or as required to translate it into languages other than 271 English. 273 The limited permissions granted above are perpetual and will not be 274 revoked by the Internet Society or its successors or assigns. 276 This document and the information contained herein is provided on an 277 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 278 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 279 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 280 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 281 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 283 Acknowledgement 285 Funding for the RFC editor function is currently provided by the 286 Internet Society.