CBOR Common Deterministic Encoding (CDE)

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 17 April 2026.¶

Copyright Notice

Copyright (c) 2025 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 and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

CBOR (STD 94, RFC 8949) defines the concept of "Deterministically Encoded CBOR" in its Section 4.2, determining one specific way to encode each particular CBOR value. This definition is instantiated by "core requirements", providing some flexibility for application specific decisions; this makes it harder than necessary to offer Deterministic Encoding as a selectable feature of generic CBOR encoders.¶

The present specification documents the Best Current Practice for CBOR Common Deterministic Encoding (CDE), which can be shared by a large set of applications with potentially diverging detailed application requirements.¶

The document also discusses the desire for partial implementations, which can be another reason for constraining CBOR encoders, and singles out the encoding constraint "definite-length-only" as a likely constraint to be used in application protocol and media type definitions.¶

This specification updates RFC 8949 in that it provides clarifications and definitions of additional terms as well as more examples and explanatory text; it does not make technical changes to RFC 8949.¶

2. Encoding Choices in CBOR

In many cases, CBOR provides more than one way to encode a data item, i.e., to serialize it into a sequence of bytes that is well-formed CBOR. This flexibility can provide convenience for the generator of the encoded data item, but handling the resulting variation can also put an onus on the decoder. In general, there is no single perfect encoding choice that is optimal for all applications. Determining whether encoding constraints are needed and, if yes, choosing the right encoding constraints can be one element of application protocol design. Having predefined sets of such choices is a useful way to reduce variation between applications, enabling generic implementations.¶

The default choice of course is not to employ any encoding constraints at all. The name well-formed is a good name for the empty set of encoding constraints, as well-formed CBOR is the baseline that is required for any interoperability. Many CBOR applications have no need for encoding constraints and therefore have no requirement beyond well-formed encoding.¶

Still, an encoder has to make a decision at some point, even if it could use any well-formed CBOR encoding. Section 4.1 of RFC 8949 [STD94] provides a recommendation for a Preferred Serialization. This recommendation is a useful guideline for generic encoders, and it is a good choice for specialized encoders for most applications. Its main constraint is to choose the shortest head (Section 3 of RFC 8949 [STD94]) that preserves the value of a data item (shortest-head encoding constraint). In addition, tag definitions can specify a preferred serialization for a tag (Section 3.4 of RFC 8949 [STD94]); the shortest-head encoding constraint together with the preferred serializations of tags constitute the preferred-serialization encoding constraint. Typically, this encoding constraint is relevant only for the encoder, as there is nothing to be gained by enforcing it by itself in a decoder, which will instead accept all well-formed CBOR.¶

Preferred Serialization allows indefinite length encoding (Section 3.2 of RFC 8949 [STD94]), which does not express the length of a string, an array, or a map in its head. Supporting both definite length and indefinite length encoding is an additional onus on the decoder. Many applications therefore choose not to use indefinite length encoding at all (definite-length-encoding encoding constraint), which enables the use of partial implementations that do not support decoding indefinite length encoding. In contrast to preferred-serialization, relying on this constraint enforces the choice at the decoder, we therefore speak about an interoperability constraint.¶

Combining preferred-serialization with definite-length-encoding still allows some variation. Specifically, there is more than one serialization for data items that contain maps that have more than one entry: The order of serialization of map entries in a map is not significant in CBOR (the same as in JSON), so maps with more than one entry have all permutations of these entries as valid serializations.¶

The encoding constraint lexicographic-map-sorting defines a common order for the entries in a map, requiring lexicographic ordering for the representations of the map keys. For many applications, ensuring this common order is an additional onus on the generator that is not actually needed, so they do not choose to apply this encoding constraint. However, there are several use cases for Deterministic Serialization (further discussed in Section 2 of [I-D.bormann-cbor-det]), and if the objective is minimal effort for the consuming application, deterministic map ordering can be useful even outside those use cases. For most of these use cases, the benefits of the encoding constraints for deterministic serialization not only require the encoder to follow them, but also need the constraints to be enforced ("checked") by the decoder. We speak of "checking decoders", which also turn the encoding constraints into interoperability constraints.¶

Table 1 summarizes the sets of encoding choices that have been given names in this section.¶

Note that the objective to have a deterministic serialization for a specific application data item can only be fulfilled if the application itself does not generate multiple different CBOR data items that represent that same (equivalent) application data item. We speak of the need for Application-level Deterministic Representation (ALDR), and we may want to aid achieving this by the application defining rules for ALDR (see also Appendix B). Where Deterministic Representation is not actually needed, application-level representation rules of course can still be useful to facilitate processing at the recipient.¶

3. CBOR Common Deterministic Encoding (CDE)

This specification documents the CBOR Common Deterministic Encoding (CDE) Best Current Practice that is based on the Core Deterministic Encoding Requirements defined for CBOR in Section 4.2.1 of RFC 8949 [STD94].¶

Note that, for RFC8949, this specific set of requirements is elective — in principle, other variants of deterministic encoding can be defined (and have been, now being phased out, as detailed in Section 4.2.3 of RFC 8949 [STD94]). In many applications of CBOR, deterministic encoding is not used at all, as its restriction of choices can create some additional performance cost and code complexity.¶

[STD94]'s "Core Deterministic Encoding Requirements" are designed to provide well-understood and easy-to-implement rules while maximizing coverage, i.e., the subset of CBOR data items that are fully specified by these rules, and also placing minimal burden on implementations.¶

Formally, Common Deterministic Encoding (CDE) is an encoding constraint (named cde for short), built from multiple constituent encoding constraints (which may, in turn, be built from multiple constituent encoding constraints). As discussed in Section 2, CDE combines the constraints of preferred-serialization with definite-length-only and the lexicographic-map-sorting constraint.¶

The remaining section discusses the three constituent encoding constraints from which cde is defined.¶

4. CDDL support

CDDL defines the structure of CBOR data items at the data model level; it enables being specific about the data items allowed in a particular place. It does not specify encoding; CBOR protocols can specify the use of CDE (or simply definite-length-only encoding) independent of the CDDL data model.¶

CDDL operates by restricting the set of data-model level data items. E.g., CDDL allows the specification of a floating point data item as "float16"; this means the application data model only foresees data that can be encoded as [IEEE754] binary16. Note that specifying "float32" for a floating point data item enables all floating point values that can be represented as binary32; this includes values that can also be represented as binary16 and that will be so represented in Preferred Serialization.¶

[RFC8610] defines control operators to indicate that the contents of a byte string carries a CBOR-encoded data item (.cbor) or a sequence of CBOR-encoded data items (.cborseq).¶

CDDL specifications may want to specify that the data items should be encoded in Common CBOR Deterministic Encoding. The present specification adds two CDDL control operators that can be used for this.¶

The control operators .cde and .cdeseq are exactly like .cbor and .cborseq except that they also require the encoded data item(s) to be encoded according to CDE. Note that there is no .dlo or .dloseq for definite-length-only, as, so far, a requirement for these hasn't been detected.¶

For example, a byte string of embedded CBOR that is to be encoded according to CDE can be formalized as:¶

leaf = #6.24(bytes .cde any)

More importantly, if the encoded data item also needs to have a specific structure, this can be expressed by the right-hand side (instead of using the most general CDDL type any here).¶

(Note that the .cdeseq control operator does not enable specifying different deterministic encoding requirements for the elements of the sequence. If a use case for such a feature becomes known, it could be added, or the CBOR sequence could be constructed with .join (Section 3.1 of [RFC9741]).)¶

Obviously, specifications that document ALDR rules can define related control operators that also embody the processing required by those ALDR rules, and are encouraged to do so.¶

5. Security Considerations

The security considerations in Section 10 of RFC 8949 [STD94] apply. The use of deterministic encoding can mitigate issues arising out of the use of non-preferred serializations specially crafted by an attacker. However, this effect only accrues if the decoder actually checks that deterministic encoding was applied correctly. More generally, additional security properties of deterministic encoding can rely on this check being performed properly.¶

6. IANA Considerations

RFC Editor: please replace RFCXXXX with the RFC number of this RFC and remove this note.¶

This document requests IANA to register the contents of Table 2 into the registry "CDDL Control Operators" of the [IANA.cddl] registry group:¶

7. References

Appendix A. Information Model, Data Model and Serialization

This appendix is informative.¶

For a good understanding of this document, it is helpful to understand the difference between an information model, a data model and serialization.¶

CBOR does not provide facilities for expressing information models. They are mentioned here for completeness and to provide some context.¶

CBOR defines a palette of basic data items that can be grouped into data types such as the usual integer or floating-point numbers, text or byte strings, arrays and maps, and certain special "simple values" such as Booleans and null. Extended data types may be constructed from these basic types. These basic and extended types are used to construct the data model of a CBOR protocol. One notation that is often used for describing the data model of a CBOR protocol is CDDL [RFC8610]. The various types of data items in the data model are serialized per RFC 8949 [STD94] to create encoded CBOR data items.¶

Appendix B. Application-level Deterministic Representation

This appendix is informative.¶

CBOR application protocols are agreements about how to use CBOR for a specific application or set of applications.¶

For a CBOR protocol to provide deterministic representation, both the encoding and application layer must be deterministic. While CDE ensures determinism at the encoding layer, requirements at the application layer may also be necessary.¶

Application protocols make representation decisions in order to constrain the variety of ways in which some aspect of the information model could be represented in the CBOR data model for the application. For instance, there are several CBOR tags that can be used to represent a time stamp (such as tag 0, 1, 1001), each with some specific properties.¶

Application protocols that need to represent a timestamp typically choose a specific tag and further constrain its use where necessary (e.g., tag 1001 was designed to cover a wide variety of applications [RFC9581]). Where no tag is available, the application protocol can design its own format for some application data. Even where a tag is available, the application data can choose to use its definitions without actually encoding the tag (e.g., by using its content in specific places in an "unwrapped" form).¶

Another source of application layer variability comes from the variety of number types CBOR offers. For instance, the number 2 can be represented as an integer, float, big number, decimal fraction and other. Most protocols designs will just specify one number type to use, and that will give determinism, but here’s an example specification that doesn’t:¶

Applications that require Deterministic Representation, and that derive CBOR data items from application data without maintaining a record of which choices are to be made when representing these application data, generally make rules for these choices as part of the application protocol. In this document, we speak about these choices as Application-level Deterministic Representation Rules (ALDR rules for short).¶

CDE provides for encoding commonality between different applications of CBOR once these application-level choices have been made. It can be useful for an application or a group of applications to document their choices aimed at deterministic representation of application data in a general way, constraining the set of data items handled (exclusions, e.g., no compressed point representations) and defining further mappings (reductions, e.g., conversions to uncompressed form) that help the application(s) get by with the exclusions. This can be done in the application protocol specification (as in [RFC9679]) or as a separate document.¶

ALDR rules (including rules specified in a ALDR ruleset document) enable simply using implementations of the common CDE; they do not "fork" CBOR in the sense of requiring distinct generic encoder/decoder implementations for each application.¶

An implementation of specific ALDR rules combined with a CDE implementation produces well-formed, deterministically encoded CBOR according to [STD94], and existing generic CBOR decoders will therefore be able to decode it, including those that check for Deterministic Encoding ("CDE-checking decoders", see also Appendix C). Similarly, generic CBOR encoders will be able to produce valid CBOR that can be ingested by an implementation that enforces an application's ALDR rules if the encoder was handed data model level information from an application that simply conformed to those ALDR rules.¶

Please note that the separation between standard CBOR processing and the processing required by the ALDR rules is a conceptual one: Instead of employing generic encoders/decoders, both ALDR rule processing and standard CBOR processing can be combined into a specialized encoder/decoder specifically designed for a particular set of ALDR rules.¶

ALDR rules are intended to be used in conjunction with an application, which typically will naturally use a subset of the CBOR generic data model, which in turn influences which subset of the ALDR rules is used by the specific application (in particular if the application simply references a more general ALDR ruleset document). As a result, ALDR rules themselves place no direct requirement on what minimum subset of CBOR is implemented. For instance, a set of ALDR rules might include rules for the processing of floating point values, but there is no requirement that implementations of that set of ALDR rules support floating point numbers (or any other kind of number, such as arbitrary precision integers or 64-bit negative integers) when they are used with applications that do not use them.¶

Appendix C. Implementers' Checklists

This appendix is informative. It provides brief checklists that implementers can use to check their implementations. It uses RFC2119 language, specifically the keyword MUST, to highlight the specific items that implementers may want to check. It does not contain any normative mandates. This appendix is informative.¶

Notes:¶

• This is largely a restatement of parts of Section 4 of RFC 8949 [STD94]. The purpose of the restatement is to aid the work of implementers, not to redefine anything.¶

  Preferred Serialization Encoders as well as CDE Encoders and CDE-checking Decoders have certain properties that are expressed using RFC2119 keywords in this appendix.¶

• Duplicate map keys are never valid in CBOR at all (see list item "Major type 5" in Section 3.1 of RFC 8949 [STD94]) no matter what sort of serialization is used. Of the various strategies listed in Section 5.6 of RFC 8949 [STD94], detecting duplicates and handling them as an error instead of passing invalid data to the application is the most robust one; achieving this level of robustness is a mark of quality of implementation.¶

• Preferred serialization and CDE only affect serialization. They do not place any requirements, exclusions, mappings or such on the data model level. ALDR rules such as the ALDR ruleset defined by dCBOR are different as they can affect the data model by restricting some values and ranges.¶

• CBOR decoders in general (as opposed to "CDE-checking decoders" specifically advertised as supporting CDE) are not required to check for preferred serialization or CDE and reject inputs that do not fulfill these requirements. However, in an environment that employs deterministic encoding, employing non-checking CBOR decoders negates many of its benefits. Decoder implementations that advertise "support" for preferred serialization or CDE need to check the encoding and reject input that is not encoded to the encoding specification in use. Again, ALDR rules such as those in dCBOR may pose additional requirements, such as requiring rejection of non-conforming inputs.¶

  If a generic decoder needs to be used that does not "support" CDE, a simple (but somewhat clumsy) way to check its input for proper CDE encoding is to re-encode the decoded data with CDE and check for bit-to-bit equality with the original input.¶

Appendix D. Encoding Examples

The following three tables provide examples of CDE-encoded CBOR data items, each giving Diagnostic Notation (EDN [I-D.ietf-cbor-edn-literals]), the encoded data item in hexadecimal, and a comment:¶

• The comments use f16, f32, and f64 as abbreviations for 16-bit float (half precision, C language _Float16), 32-bit float (single precision, C language _Float32, fits in float), and 64-bit float (double precision, C language _Float64, fits in double), respectively, as well as qNaN for quiet NaN and sNaN for signaling NaN.¶

• As there is no established EDN for notating NaNs with non-zero payloads at the time of writing, this table uses float'hex', where hex is a hexadecimal representation of the IEEE 754 interchange format for the NaN value.¶

Implementers that want to use these examples as test input may be interested in the file example-table-input.csv in the github repository cbor-wg/draft-ietf-cbor-cde.¶

Appendix E. Examples for Preferred Serialization of Integers

This appendix looks at the set of encoded CBOR data items that represent the integer number 1. Preferred Serialization chooses one of them (0x01), which is then always used to encode the number. The CDE encoding constraints include those of preferred serialization. A CDE-checking decoder checks that no other serialization is being used in the encoded data item being decoded.¶

For the integer number 100000000000000000000 (1 with 20 decimal zeros), the only serialization that meets the preferred-serialization and definite-length-only constraints is:¶

C2                       # tag(2)
   49                    # bytes(9)
      056BC75E2D63100000 #

(Note that, in addition to this serialization, there are multiple serializations that would also count as preferred serializations, as the preferred serialization constraint by itself does not exclude indefinite length encoding of the byte string that is the content of tag 2.)¶

Appendix F. Example Code for Encoding into 16-bit Floating Point

Appendix D (Half-Precision) of RFC 8949 [STD94] provides example C and Python code for decoding 16-bit ("Half Precision", binary16) floating point numbers. Providing this code was considered important at the time to aid in the creation of generic decoders.¶

Given that CDE implementations that support floating point Numbers not only need to decode, but also to encode their 16-bit format, this appendix provides example C code to convert a floating point number that is in 64-bit form ("Double Precision", binary64) into binary16.¶

If such a conversion is not possible (i.e., there is no 16-bit representation for the 64-bit value given), the function try_float16_encode returns -1. Otherwise it returns a two-byte integer (range 0x0000 to 0xFFFF) that, prefixed with 0xF9, is suitable to encode the value.¶

/* returns 0..0xFFFF if float16 encoding possible, -1 otherwise.
   b64 is a binary64 floating point as an unsigned long. */
int try_float16_encode(unsigned long b64) {
  unsigned long s16 = b64 >> 48 & 0x8000UL;
  unsigned long mant = b64 & 0xfffffffffffffUL;
  unsigned long exp = b64 >> 52 & 0x7ffUL;
  if (exp == 0 && mant == 0)    /* f64 denorms are out of range */
    return s16;                 /* so handle 0.0 and -0.0 only */
  if (exp >= 999 && exp < 1009) { /* f16 denorm, exp16 = 0 */
    if (mant & ((1UL << (1051 - exp)) - 1))
      return -1;                /* bits lost in f16 denorm */
    return s16 + ((mant + 0x10000000000000UL) >> (1051 - exp));
  }
  if (mant & 0x3ffffffffffUL)   /* bits lost in f16 */
    return -1;
  if (exp >= 1009 && exp <= 1038) /* normalized f16 */
    return s16 + ((exp - 1008) << 10) + (mant >> 42);
  if (exp == 2047)              /* Inf, NaN */
    return s16 + 0x7c00 + (mant >> 42);
  return -1;
}

List of Figures

Figure 1:

Example C Code for a Half-Precision Encoder¶

List of Tables

Table 1:

Constraints on the Serialization of CBOR¶

Table 2:

New control operators to be registered¶

Table 3:

A three-layer model of information representation¶

Table 4:

CDE: Integer Value Examples¶

Table 5:

CDE: Floating Point Value Examples¶

Table 6:

Failing Examples: Not CDE¶

Table 7:

Serializations of integer number 1¶

Acknowledgments

An early version of this document was based on the work of Wolf McNally and Christopher Allen as documented in [I-D.mcnally-deterministic-cbor], which serves as an example for an ALDR ruleset document. We would like to explicitly acknowledge that this work has contributed greatly to shaping the concept of a CBOR Common Deterministic Encoding and the use of ALDR rules/rulesets on top of that. Mikolai Gütschow proposed adding Section 2. Anders Rundgren provided most of the initial text that turned into Appendix D, Laurence Lundblade provided examples for "NaN" (not a number) floating point values.¶

Contributors

Laurence provided most of the text that became Appendix A and Appendix C.¶

Author's Address