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

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/