idnits 2.17.1 draft-multiformats-multibase-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The abstract seems to contain references ([2], [3], [4], [5], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 28, 2018) is 1943 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) -- Looks like a reference, but probably isn't: '1' on line 160 -- Looks like a reference, but probably isn't: '2' on line 162 -- Looks like a reference, but probably isn't: '3' on line 164 -- Looks like a reference, but probably isn't: '4' on line 166 -- Looks like a reference, but probably isn't: '5' on line 168 -- Looks like a reference, but probably isn't: '6' on line 170 -- Looks like a reference, but probably isn't: '7' on line 208 -- Looks like a reference, but probably isn't: '8' on line 258 == Missing Reference: 'RFC4648' is mentioned on line 250, but not defined == Unused Reference: 'RFC2119' is defined on line 132, but no explicit reference was found in the text == Unused Reference: 'RFC6234' is defined on line 137, but no explicit reference was found in the text == Unused Reference: 'RFC7693' is defined on line 142, but no explicit reference was found in the text == Unused Reference: 'RFC6150' is defined on line 149, but no explicit reference was found in the text == Unused Reference: 'RFC6151' is defined on line 153, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 6234 ** Downref: Normative reference to an Informational RFC: RFC 7693 Summary: 4 errors (**), 0 flaws (~~), 7 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Benet 3 Internet-Draft Protocol Labs 4 Intended status: Standards Track M. Sporny 5 Expires: July 1, 2019 Digital Bazaar 6 December 28, 2018 8 The Multibase Data Format 9 draft-multiformats-multibase-00 11 Abstract 13 Raw binary data is often encoded using a mechanism that enables the 14 data to be included in human-readable text-based formats. This 15 mechanism is often referred to as "base-encoding the data". Base- 16 encoding is often used when expressing binary data in hyperlinks, 17 cryptographic keys in web pages, or security tokens in application 18 software. There are a variety of base-encodings, such as base32, 19 base58, and base64. It is not always possible to differentiate one 20 base-encoding from another. The purpose of this specification is to 21 provide a mechanism to be able to deterministically identify the 22 base-encoding for a particular string of data. 24 Feedback 26 This specification is a joint work product of Protocol Labs [1], the 27 W3C Digital Verification Community Group [2], and the W3C Credentials 28 Community Group [3]. Feedback related to this specification should 29 logged in the issue tracker [4] or be sent to public- 30 credentials@w3.org [5]. . 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at https://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on July 1, 2019. 49 Copyright Notice 51 Copyright (c) 2018 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (https://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 2. The Multibase Format . . . . . . . . . . . . . . . . . . . . 3 65 2.1. A Multibase Example . . . . . . . . . . . . . . . . . . . 3 66 3. References . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 3.1. Normative References . . . . . . . . . . . . . . . . . . 3 68 3.2. Informative References . . . . . . . . . . . . . . . . . 4 69 3.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 Appendix A. Security Considerations . . . . . . . . . . . . . . 4 71 Appendix B. Test Values . . . . . . . . . . . . . . . . . . . . 4 72 B.1. Hexadecimal upper-case encoding . . . . . . . . . . . . . 5 73 B.2. Base-32 upper-case encoding, no padding . . . . . . . . . 5 74 B.3. Base-58 Bitcoin encoding . . . . . . . . . . . . . . . . 5 75 B.4. Base-64 with padding and MIME-encoding . . . . . . . . . 5 76 Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 5 77 Appendix D. IANA Considerations . . . . . . . . . . . . . . . . 5 78 D.1. The Multibase Algorithms Registry . . . . . . . . . . . . 5 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 81 1. Introduction 83 This specification describes a forward-compatible data model for 84 expressing raw binary data in a variety of base-encoding formats such 85 as base32, base58. and base64. 87 When text is encoded as bytes, we can usually use a one-size-fits-all 88 encoding (UTF-8) because we're always encoding to the same set of 256 89 bytes. When that doesn't work, usually for historical or performance 90 reasons, we can usually infer the encoding from the context. 92 However, when bytes are encoded as text (using a base encoding), the 93 choice of base encoding is often restricted by the context. Worse, 94 these restrictions can change based on where the data appears in the 95 text. In some cases, we can only use [a-z0-9]. In others, we can 96 use a larger set of characters but need a compact encoding. This has 97 lead to a large set of "base encodings", one for every use-case. 98 Unlike when encoding text to bytes, we can't just standardize around 99 a single base encoding because there is no optimal encoding for all 100 cases. 102 Unfortunately, it's not always clear what base encoding is used; 103 that's where this specification comes in. It answers the question: 105 Given data 'd' encoded into text 's', what base is it encoded with? 107 2. The Multibase Format 109 A multibase-encoded value follows a simple format: 111 base-encoding-character base-encoded-data 113 The encoding algorithm is a single character value that is always the 114 first byte of the data. The possible values for this field are 115 provided in The Multibase Algorithm Registry [6]. 117 2.1. A Multibase Example 119 The following is an encoding of "Hello World!" using the version of 120 base-58 that utilizes the Bitcoin encoding character set: 122 z2NEpo7TZRRrLZSi2U 124 The first byte (z) specifies the multibase encoding algorithm. The 125 rest of the data specifies the value of the output of the multibase 126 encoding algorithm. 128 3. References 130 3.1. Normative References 132 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 133 Requirement Levels", BCP 14, RFC 2119, 134 DOI 10.17487/RFC2119, March 1997, 135 . 137 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 138 (SHA and SHA-based HMAC and HKDF)", RFC 6234, 139 DOI 10.17487/RFC6234, May 2011, 140 . 142 [RFC7693] Saarinen, M-J., Ed. and J-P. Aumasson, "The BLAKE2 143 Cryptographic Hash and Message Authentication Code (MAC)", 144 RFC 7693, DOI 10.17487/RFC7693, November 2015, 145 . 147 3.2. Informative References 149 [RFC6150] Turner, S. and L. Chen, "MD4 to Historic Status", 150 RFC 6150, DOI 10.17487/RFC6150, March 2011, 151 . 153 [RFC6151] Turner, S. and L. Chen, "Updated Security Considerations 154 for the MD5 Message-Digest and the HMAC-MD5 Algorithms", 155 RFC 6151, DOI 10.17487/RFC6151, March 2011, 156 . 158 3.3. URIs 160 [1] https://protocol.ai/ 162 [2] https://w3c-dvcg.github.io/ 164 [3] https://w3c-ccg.github.io/ 166 [4] https://github.com/w3c-dvcg/multibase/issues 168 [5] mailto:public-credentials@w3.org 170 [6] #mb-registry 172 [7] http://www.iana.org/assignments/multibase-algorithms 174 [8] https://github.com/multiformats/multibase/blob/master/ 175 multibase.csv 177 Appendix A. Security Considerations 179 There are a number of security considerations to take into account 180 when implementing or utilizing this specification. TBD 182 Appendix B. Test Values 184 The multibase examples are chosen to show different encoding 185 algorithms and different output lengths at play. The input test data 186 for all of the examples in this section is: 188 B.1. Hexadecimal upper-case encoding 190 B.2. Base-32 upper-case encoding, no padding 192 B.3. Base-58 Bitcoin encoding 194 B.4. Base-64 with padding and MIME-encoding 196 Appendix C. Acknowledgements 198 The editors would like to thank the following individuals for 199 feedback on and implementations of the specification (in alphabetical 200 order): 202 Appendix D. IANA Considerations 204 D.1. The Multibase Algorithms Registry 206 The following initial entries should be added to the Multibase 207 Algorithms Registry to be created and maintained at (the suggested 208 URI) http://www.iana.org/assignments/multibase-algorithms [7]: 210 +-------------------+-------------+--------+------------------------+ 211 | Algorithm | Identifier | Status | Specification | 212 | | (character) | | | 213 +-------------------+-------------+--------+------------------------+ 214 | identity | 0x00 | active | 8-bit binary (encoder | 215 | | | | and decoder keeps data | 216 | | | | unmodified) | 217 | base1 | 1 | active | unary (11111) | 218 | base2 | 0 | active | binary (01010101) | 219 | base8 | 7 | active | octal | 220 | base10 | 9 | active | decimal | 221 | base16 | f | active | hexadecimal | 222 | base16upper | F | active | hexadecimal | 223 | base32hex | v | active | RFC 4648 [RFC4648] no | 224 | | | | padding - highest char | 225 | base32hexupper | V | active | RFC 4648 [RFC4648] no | 226 | | | | padding - highest char | 227 | base32hexpad | t | active | RFC 4648 [RFC4648] | 228 | | | | with padding | 229 | base32hexpadupper | T | active | RFC 4648 [RFC4648] | 230 | | | | with padding | 231 | base32 | b | active | RFC 4648 [RFC4648] no | 232 | | | | padding | 233 | base32upper | B | active | RFC 4648 [RFC4648] no | 234 | | | | padding | 235 | base32pad | c | active | RFC 4648 [RFC4648] | 236 | | | | with padding | 237 | base32padupper | C | active | RFC 4648 [RFC4648] | 238 | | | | with padding | 239 | base32z | h | active | z-base-32 (used by | 240 | | | | Tahoe-LAFS) | 241 | base58flickr | Z | active | base58 flicker | 242 | base58btc | z | active | base58 bitcoin | 243 | base64 | m | active | RFC 4648 [RFC4648] no | 244 | | | | padding | 245 | base64pad | M | active | RFC 4648 [RFC4648] | 246 | | | | with padding - MIME | 247 | | | | encoding | 248 | base64url | u | active | RFC 4648 [RFC4648] no | 249 | | | | padding | 250 | base64urlpad | U | active | RFC 4648 [RFC4648] | 251 | | | | with padding | 252 +-------------------+-------------+--------+------------------------+ 254 Table 1: Multihash Algorithms Registry 256 NOTE: The most up to date place for developers to find the table 257 above is https://github.com/multiformats/multibase/blob/master/ 258 multibase.csv [8]. 260 Authors' Addresses 262 Juan Benet 263 Protocol Labs 264 548 Market Street, #51207 265 San Francisco, CA 94104 266 US 268 Phone: +1 619 957 7606 269 Email: juan@protocol.ai 270 URI: http://juan.benet.ai/ 272 Manu Sporny 273 Digital Bazaar 274 203 Roanoke Street W. 275 Blacksburg, VA 24060 276 US 278 Phone: +1 540 961 4469 279 Email: msporny@digitalbazaar.com 280 URI: http://manu.sporny.org/