--- 1/draft-ietf-cbor-7049bis-15.txt 2020-09-30 10:15:50.950526428 -0700 +++ 2/draft-ietf-cbor-7049bis-16.txt 2020-09-30 10:15:51.110530460 -0700 @@ -1,64 +1,50 @@ Network Working Group C. Bormann Internet-Draft Universitaet Bremen TZI Obsoletes: 7049 (if approved) P. Hoffman Intended status: Standards Track ICANN -Expires: 28 March 2021 24 September 2020 +Expires: 3 April 2021 30 September 2020 Concise Binary Object Representation (CBOR) - draft-ietf-cbor-7049bis-15 + draft-ietf-cbor-7049bis-16 Abstract The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack. This document is a revised edition of RFC 7049, with editorial improvements, added detail, and fixed errata. This revision formally obsoletes RFC 7049, while keeping full compatibility of the interchange format from RFC 7049. It does not create a new version of the format. -Contributing - - This note is to be removed before publishing as an RFC. - - This document is being worked on in the CBOR Working Group. Please - contribute on the mailing list there, or in the GitHub repository for - this draft: https://github.com/cbor-wg/CBORbis - - The charter for the CBOR Working Group says that the WG will update - RFC 7049 to fix verified errata. Security issues and clarifications - may be addressed, but changes to this document will ensure backward - compatibility for popular deployed codebases. This document will be - targeted at becoming an Internet Standard. - Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on 28 March 2021. + This Internet-Draft will expire on 3 April 2021. Copyright Notice Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights @@ -67,28 +53,28 @@ as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Objectives . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 2. CBOR Data Models . . . . . . . . . . . . . . . . . . . . . . 8 2.1. Extended Generic Data Models . . . . . . . . . . . . . . 9 - 2.2. Specific Data Models . . . . . . . . . . . . . . . . . . 10 + 2.2. Specific Data Models . . . . . . . . . . . . . . . . . . 9 3. Specification of the CBOR Encoding . . . . . . . . . . . . . 10 3.1. Major Types . . . . . . . . . . . . . . . . . . . . . . . 11 3.2. Indefinite Lengths for Some Major Types . . . . . . . . . 14 3.2.1. The "break" Stop Code . . . . . . . . . . . . . . . . 14 - 3.2.2. Indefinite-Length Arrays and Maps . . . . . . . . . . 15 - 3.2.3. Indefinite-Length Byte Strings and Text Strings . . . 17 - 3.2.4. Summary of indefinite-length use of major types . . . 18 + 3.2.2. Indefinite-Length Arrays and Maps . . . . . . . . . . 14 + 3.2.3. Indefinite-Length Byte Strings and Text Strings . . . 16 + 3.2.4. Summary of indefinite-length use of major types . . . 17 3.3. Floating-Point Numbers and Values with No Content . . . . 18 3.4. Tagging of Items . . . . . . . . . . . . . . . . . . . . 20 3.4.1. Standard Date/Time String . . . . . . . . . . . . . . 23 3.4.2. Epoch-based Date/Time . . . . . . . . . . . . . . . . 23 3.4.3. Bignums . . . . . . . . . . . . . . . . . . . . . . . 24 3.4.4. Decimal Fractions and Bigfloats . . . . . . . . . . . 25 3.4.5. Content Hints . . . . . . . . . . . . . . . . . . . . 26 3.4.5.1. Encoded CBOR Data Item . . . . . . . . . . . . . 27 3.4.5.2. Expected Later Encoding for CBOR-to-JSON Converters . . . . . . . . . . . . . . . . . . . . 27 @@ -120,26 +106,26 @@ 7.2. Curating the Additional Information Space . . . . . . . . 47 8. Diagnostic Notation . . . . . . . . . . . . . . . . . . . . . 47 8.1. Encoding Indicators . . . . . . . . . . . . . . . . . . . 49 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49 9.1. Simple Values Registry . . . . . . . . . . . . . . . . . 50 9.2. Tags Registry . . . . . . . . . . . . . . . . . . . . . . 50 9.3. Media Type ("MIME Type") . . . . . . . . . . . . . . . . 51 9.4. CoAP Content-Format . . . . . . . . . . . . . . . . . . . 51 9.5. The +cbor Structured Syntax Suffix Registration . . . . . 52 10. Security Considerations . . . . . . . . . . . . . . . . . . . 53 - 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 56 - 11.1. Normative References . . . . . . . . . . . . . . . . . . 56 + 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 55 + 11.1. Normative References . . . . . . . . . . . . . . . . . . 55 11.2. Informative References . . . . . . . . . . . . . . . . . 57 - Appendix A. Examples of Encoded CBOR Data Items . . . . . . . . 60 - Appendix B. Jump Table for Initial Byte . . . . . . . . . . . . 64 - Appendix C. Pseudocode . . . . . . . . . . . . . . . . . . . . . 67 + Appendix A. Examples of Encoded CBOR Data Items . . . . . . . . 59 + Appendix B. Jump Table for Initial Byte . . . . . . . . . . . . 63 + Appendix C. Pseudocode . . . . . . . . . . . . . . . . . . . . . 66 Appendix D. Half-Precision . . . . . . . . . . . . . . . . . . . 69 Appendix E. Comparison of Other Binary Formats to CBOR's Design Objectives . . . . . . . . . . . . . . . . . . . . . . . 70 E.1. ASN.1 DER, BER, and PER . . . . . . . . . . . . . . . . . 71 E.2. MessagePack . . . . . . . . . . . . . . . . . . . . . . . 71 E.3. BSON . . . . . . . . . . . . . . . . . . . . . . . . . . 72 E.4. MSDTP: RFC 713 . . . . . . . . . . . . . . . . . . . . . 72 E.5. Conciseness on the Wire . . . . . . . . . . . . . . . . . 72 Appendix F. Well-formedness errors and examples . . . . . . . . 73 F.1. Examples for CBOR data items that are not well-formed . . 74 @@ -730,27 +714,28 @@ 46756e -- "Fun" F5 -- First value, true 63 -- Second key, UTF-8 string length 3 416d74 -- "Amt" 21 -- Second value, -2 FF -- "break" 3.2.3. Indefinite-Length Byte Strings and Text Strings Indefinite-length strings are represented by a byte containing the - major type and additional information value of 31, followed by a - series of zero or more byte or text strings ("chunks") that have - definite lengths, followed by the "break" stop code (Section 3.2.1). - The data item represented by the indefinite-length string is the - concatenation of the chunks (i.e., the empty byte or text string, - respectively, if no chunk is present). (Note that zero-length - chunks, while not particularly useful, are permitted.) + major type for byte string or text string with an additional + information value of 31, followed by a series of zero or more strings + of the specified type ("chunks") that have definite lengths, and + finished by the "break" stop code (Section 3.2.1). The data item + represented by the indefinite-length string is the concatenation of + the chunks. If no chunks are present, the data item is an empty + string of the specified type. Zero-length chunks, while not + particularly useful, are permitted. If any item between the indefinite-length string indicator (0b010_11111 or 0b011_11111) and the "break" stop code is not a definite-length string item of the same major type, the string is not well-formed. The design does not allow nesting indefinite-length strings as chunks into indefinite-length strings. If it were allowed, it would require decoder implementations to keep a stack, or at least a count, of nesting levels. It is unnecessary on the encoder side because the @@ -1613,23 +1598,23 @@ sequence of CBOR data items concatenated back-to-back. In such an environment, the decoder immediately begins decoding a new data item if data is found after the end of a previous data item. Not all of the bytes making up a data item may be immediately available to the decoder; some decoders will buffer additional data until a complete data item can be presented to the application. Other decoders can present partial information about a top-level data item to an application, such as the nested data items that could already be decoded, or even parts of a byte string that hasn't - completely arrived yet. Such an application also MUST have matching - streaming security mechanism, where the desired protection is - available for incremental data presented to the application. + completely arrived yet. Such an application also MUST have a + matching streaming security mechanism, where the desired protection + is available for incremental data presented to the application. Note that some applications and protocols will not want to use indefinite-length encoding. Using indefinite-length encoding allows an encoder to not need to marshal all the data for counting, but it requires a decoder to allocate increasing amounts of memory while waiting for the end of the item. This might be fine for some applications but not others. 5.2. Generic Encoders and Decoders @@ -2248,23 +2233,20 @@ the chunk structure need to be notated as (_ ''), (_ ""), etc. 9. IANA Considerations IANA has created two registries for new CBOR values. The registries are separate, that is, not under an umbrella registry, and follow the rules in [RFC8126]. IANA has also assigned a new MIME media type and an associated Constrained Application Protocol (CoAP) Content-Format entry. - [To be removed by RFC editor:] IANA is requested to update these - registries to point to the present document instead of RFC 7049. - 9.1. Simple Values Registry IANA has created the "Concise Binary Object Representation (CBOR) Simple Values" registry at [IANA.cbor-simple-values]. The initial values are shown in Table 4. New entries in the range 0 to 19 are assigned by Standards Action. It is suggested that these Standards Actions allocate values starting with the number 16 in order to reserve the lower numbers for contiguous blocks (if any). @@ -2395,26 +2377,20 @@ "xxx/yyy+cbor". Security Considerations: See Section 10 of this document Contact: IETF CBOR Working Group cbor@ietf.org (mailto:cbor@ietf.org) or IETF Applications and Real-Time Area art@ietf.org (mailto:art@ietf.org) Author/Change Controller: The IESG iesg@ietf.org (mailto:iesg@ietf.org) - // Editors' note: RFC 6838 has a template field Author/Change - // controller, the descriptive text of which makes clear that this - is - // the change controller, not the author. Go figure. There is no - // separate author entry as in the media types registry. (RFC - // editor: Please remove this note before publication.) 10. Security Considerations A network-facing application can exhibit vulnerabilities in its processing logic for incoming data. Complex parsers are well known as a likely source of such vulnerabilities, such as the ability to remotely crash a node, or even remotely execute arbitrary code on it. CBOR attempts to narrow the opportunities for introducing such vulnerabilities by reducing parser complexity, by giving the entire range of encodable values a meaning where possible.