CBOR C. Bormann Internet-Draft Universität Bremen TZI Intended status: Best Current Practice 10 February 2025 Expires: 14 August 2025 CBOR Common Deterministic Encoding (CDE) draft-ietf-cbor-cde-08 Abstract CBOR (STD 94, RFC 8949) defines "Deterministically Encoded CBOR" in its Section 4.2, providing some flexibility for application specific decisions. To facilitate Deterministic Encoding to be offered as a selectable feature of generic encoders, the present document defines a CBOR Common Deterministic Encoding (CDE) Profile that can be shared by a large set of applications with potentially diverging detailed requirements. It also defines "Basic Serialization", which stops short of the potentially more onerous requirements that make CDE fully deterministic, while employing most of its reductions of the variability needing to be handled by decoders. About This Document This note is to be removed before publishing as an RFC. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-ietf-cbor-cde/. Discussion of this document takes place on the Concise Binary Object Representation Maintenance and Extensions (CBOR) Working Group mailing list (mailto:cbor@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/cbor/. Subscribe at https://www.ietf.org/mailman/listinfo/cbor/. Source for this draft and an issue tracker can be found at https://github.com/cbor-wg/draft-ietf-cbor-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/. Bormann Expires 14 August 2025 [Page 1] Internet-Draft CBOR CDE February 2025 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 14 August 2025. 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Structure of This Document . . . . . . . . . . . . . . . 3 1.2. Conventions and Definitions . . . . . . . . . . . . . . . 4 2. Encoding Choices in CBOR . . . . . . . . . . . . . . . . . . 4 3. CBOR Common Deterministic Encoding Profile (CDE) . . . . . . 6 4. CDDL support . . . . . . . . . . . . . . . . . . . . . . . . 9 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 7.1. Normative References . . . . . . . . . . . . . . . . . . 10 7.2. Informative References . . . . . . . . . . . . . . . . . 11 Appendix A. Application-level Deterministic Representation . . . 12 Appendix B. Implementers' Checklists . . . . . . . . . . . . . . 15 B.1. Preferred Serialization . . . . . . . . . . . . . . . . . 16 B.1.1. Preferred Serialization Encoders . . . . . . . . . . 16 B.1.2. Preferred Serialization Decoders . . . . . . . . . . 17 B.2. Basic Serialization . . . . . . . . . . . . . . . . . . . 18 B.2.1. Basic Serialization Encoders . . . . . . . . . . . . 18 B.2.2. Basic Serialization Decoders . . . . . . . . . . . . 18 B.3. CDE . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 B.3.1. CDE Encoders . . . . . . . . . . . . . . . . . . . . 19 B.3.2. CDE Decoders . . . . . . . . . . . . . . . . . . . . 19 List of Tables . . . . . . . . . . . . . . . . . . . . . . . . . 19 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 20 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 20 Bormann Expires 14 August 2025 [Page 2] Internet-Draft CBOR CDE February 2025 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 20 1. Introduction CBOR (STD 94, RFC 8949) defines "Deterministically Encoded CBOR" in its Section 4.2, providing some flexibility for application specific decisions. To facilitate Deterministic Encoding to be offered as a selectable feature of generic encoders, the present document defines a CBOR Common Deterministic Encoding (CDE) Profile that can be shared by a large set of applications with potentially diverging detailed requirements. It also defines "Basic Serialization", which stops short of the potentially more onerous requirements that make CDE fully deterministic, while employing most of its reductions of the variability needing to be handled by decoders. 1.1. Structure of This Document After introductory material (this introduction and Section 2), Section 3 defines the CBOR Common Deterministic Encoding Profile (CDE). Section 4 defines Concise Data Definition Language (CDDL) support for indicating the use of CDE. This is followed by the conventional sections for Security Considerations (5), IANA Considerations (6), and References (7). The informative Appendix B provides brief checklists that implementers can use to check their CDE implementations. Appendix B.1 provides a checklist for implementing Preferred Serialization. Appendix B.2 introduces "Basic Serialization", a slightly more restricted form of Preferred Serialization that may be used by encoders to hit a sweet spot for maximizing interoperability with partial (e.g., constrained) CBOR decoder implementations. Appendix B.3 further restricts Basic Serialization to arrive at CDE. Instead of giving rise to the definition of application-specific, non-interoperable variants of CDE, this document identifies Application-level Deterministic Representation (ALDR) rules as a concept that is separate from CDE itself (Appendix A) and therefore out of scope for this document. ALDR rules are situated at the application-level, i.e., on top of the CDE, and address requirements on deterministic representation of application data that are specific to an application or a set of applications. ALDR rules are often provided as part of a specification for a CBOR-based protocol, or, if needed, can be provided by referencing a shared "ALDR ruleset" that is defined in a separate document. Bormann Expires 14 August 2025 [Page 3] Internet-Draft CBOR CDE February 2025 1.2. Conventions and Definitions The conventions and definitions of [STD94] apply. * The term "CBOR Application" ("application" for short) is not explicitly defined in [STD94]; this document uses it in the same sense as it is used there, specifically for applications that use CBOR as an interchange format and use (often generic) CBOR encoders/decoders to serialize/ingest the CBOR form of their application data to be exchanged. * Similarly, "CBOR Protocol" is used as in [STD94] for the protocol that governs the interchange of data in CBOR format for a specific application or set of applications. * "Representation" stands for the process, and its result, of building the representation format out of (information-model level) application data. * "Serialization" is used for the subset of this process, and its result, that represents ("serializes") data in CBOR generic data model form into encoded data items. "Encoding" is often used as a synonym when the focus is on that. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [BCP14] (RFC2119) (RFC8174) when, and only when, they appear in all capitals, as shown here. 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. 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. Choosing the right constraints on these encoding choices is one element of application protocol design. Having predefined sets of such choices is a useful way to reduce variation between applications, enabling generic implementations. Section 4.1 of RFC 8949 [STD94] provides a recommendation for a _Preferred Serialization_. This recommendation is useful for most CBOR applications, and it is a good choice 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. Bormann Expires 14 August 2025 [Page 4] Internet-Draft CBOR CDE February 2025 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. We call Preferred Serialization with this additional constraint _Basic Serialization_. Basic Serialization is a common choice for applications that need to further reduce the variability that needs to be handled by decoders, potentially maximizing interoperability with partial (e.g., constrained) CBOR decoder implementations. These constraints still allow some variation. In particular, there is more than one serialization for data items that contain maps: The order of serialization of map entries is ignored in CBOR (as it is in JSON), so maps with more than one entry have all permutations of these entries as valid Basic Serializations. _Deterministic Serialization_ builds on Basic Serialization by defining a common (namely, lexicographic) order for the entries in a map. For many applications, ensuring this common order is an additional onus on the generator that is not actually needed, so they do not choose Deterministic Serialization. However, if the objective is minimal effort for the consuming application, deterministic map ordering can be useful even outside the main use cases for Deterministic Serialization that are further discussed in Section 2 of [I-D.bormann-cbor-det]. Table 1 summarizes the increasingly restrictive sets of encoding choices that have been given names in this section. +=========================+================+==============+ | Set of Encoding Choices | Most Important | Applications | | | Constraint | | +=========================+================+==============+ | preferred | shortest | most | | | "head" variant | | +-------------------------+----------------+--------------+ | basic | + definite | many | | | lengths only | | +-------------------------+----------------+--------------+ | _deterministic_ ("CDE") | + common map | specific | | | order | | +-------------------------+----------------+--------------+ Table 1: Constraints on the Serialization of CBOR Bormann Expires 14 August 2025 [Page 5] Internet-Draft CBOR CDE February 2025 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 A). Where Deterministic Representation is not actually needed, application- level representation rules of course can still be useful to amplify the benefits of Preferred or Basic Serialization. 3. CBOR Common Deterministic Encoding Profile (CDE) This specification defines the _CBOR Common Deterministic Encoding Profile_ (CDE) based on the _Core Deterministic Encoding Requirements_ defined for CBOR in Section 4.2.1 of RFC 8949 [STD94]. Note that this specific set of requirements is elective — in principle, other variants of deterministic encoding can be defined (and have been, now being phased out slowly, as detailed in Section 4.2.3 of RFC 8949 [STD94]). In many applications of CBOR today, deterministic encoding is not used at all, as its restriction of choices can create some additional performance cost and code complexity. [STD94]'s core 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. Section 4.2.2 of RFC 8949 [STD94] picks up on the interaction of extensibility (CBOR tags) and deterministic encoding. CBOR itself uses some tags to increase the range of its basic generic data types, e.g., tags 2/3 extend the range of basic major types 0/1 in a seamless way. Section 4.2.2 of RFC 8949 [STD94] recommends handling this transition the same way as with the transition between different integer representation lengths in the basic generic data model, i.e., by mandating the preferred serialization for all integers (Section 3.4.3 of RFC 8949 [STD94]). 1. CDE turns this recommendation into a mandate: Integers that can be represented by basic major type 0 and 1 are encoded using the deterministic encoding defined for them, and integers outside this range are encoded using the preferred serialization (Section 3.4.3 of RFC 8949 [STD94]) of tag 2 and 3 (i.e., no leading zero bytes). Bormann Expires 14 August 2025 [Page 6] Internet-Draft CBOR CDE February 2025 Most tags capture more specific application semantics and therefore may be harder to define a deterministic encoding for. While the deterministic encoding of their tag internals is often covered by the _Core Deterministic Encoding Requirements_, the mapping of diverging platform application data types onto the tag contents may require additional attention to perform it in a deterministic way; see Section 3.2 of [I-D.bormann-cbor-det] for more explanation as well as examples. As the CDE would continually need to address additional issues raised by the registration of new tags, this specification recommends that new tag registrations address deterministic encoding in the context of CDE. A particularly difficult field to obtain deterministic encoding for is floating point numbers, partially because they themselves are often obtained from processes that are not entirely deterministic between platforms. See Section 3.2.2 of [I-D.bormann-cbor-det] for more details. Section 4.2.2 of RFC 8949 [STD94] presents a number of choices; these need to be made to obtain the CBOR Common Deterministic Encoding Profile (CDE). Specifically, CDE specifies (in the order of the bullet list at the end of Section 4.2.2 of RFC 8949 [STD94]): 2. Besides the mandated use of preferred serialization, there is no further specific action for the two different zero values, e.g., an encoder that is asked by an application to represent a negative floating point zero will generate 0xf98000. 3. There is no attempt to mix integers and floating point numbers, i.e., all floating point values are encoded as the preferred floating-point representation that accurately represents the value, independent of whether the floating point value is, mathematically, an integral value (choice 2 of the second bullet). Bormann Expires 14 August 2025 [Page 7] Internet-Draft CBOR CDE February 2025 4. Apart from finite and infinite numbers, [IEEE754] floating point values include NaN (not a number) values [I-D.bormann-cbor-numbers]. In CDE, there is no special handling of NaN values, except that the preferred serialization rules also apply to NaNs (with zero or non-zero payloads), using the canonical encoding of NaNs as defined in Section 6.2.1 of [IEEE754]. Specifically, this means that shorter forms of encodings for a NaN are used when that can be achieved by only removing trailing zeros in the NaN payload (example serializations are available in Appendix A.1.2 of [I-D.bormann-cbor-numbers]). Further clarifying a "should"-level statement in Section 6.2.1 of [IEEE754], the CBOR encoding always uses a leading bit of 1 in the significand to encode a quiet NaN; the use of signaling NaNs by application protocols is NOT RECOMMENDED but when presented by an application these are encoded by using a leading bit of 0. Typically, most applications that employ NaNs in their storage and communication interfaces will only use a single NaN value, quiet NaN with payload 0, which therefore deterministically encodes as 0xf97e00. 5. There is no special handling of subnormal values. 6. CDE does not presume equivalence of basic floating point values with floating point values using other representations (e.g., tag 4/5). Such equivalences and related deterministic representation rules can be added at the ALDR level if desired, e.g., by stipulating additional equivalences and deterministically choosing exactly one representation for each such equivalence, and by restricting in general the set of data item values actually used by an application. The main intent here is to preserve the basic generic data model, so applications (in their ALDR rules or by referencing a separate ALDR ruleset document, see Appendix A) can make their own decisions within that data model. E.g., an application's ALDR rules can decide that it only ever allows a single NaN value that would be encoded as 0xf97e00, so a CDE implementation focusing on this application would not need to provide processing for other NaN values. Basing the definition of both CDE and ALDR rules on the generic data model of CBOR also means that there is no effect on the Concise Data Definition Language (CDDL) [RFC8610], except where the data description is documenting specific encoding decisions for byte strings that carry embedded CBOR. Bormann Expires 14 August 2025 [Page 8] Internet-Draft CBOR CDE February 2025 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, but CBOR protocols can specify the use of CDE (or simply Basic Serialization). For instance, it 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 Basic 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. 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.) 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. Bormann Expires 14 August 2025 [Page 9] Internet-Draft CBOR CDE February 2025 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: +=========+===========+ | Name | Reference | +=========+===========+ | .cde | [RFCXXXX] | +---------+-----------+ | .cdeseq | [RFCXXXX] | +---------+-----------+ Table 2: New control operators to be registered 7. References 7.1. Normative References [BCP14] Best Current Practice 14, . At the time of writing, this BCP comprises the following: Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . Bormann Expires 14 August 2025 [Page 10] Internet-Draft CBOR CDE February 2025 [IANA.cddl] IANA, "Concise Data Definition Language (CDDL)", . [IEEE754] IEEE, "IEEE Standard for Floating-Point Arithmetic", IEEE Std 754-2019, DOI 10.1109/IEEESTD.2019.8766229, . [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, June 2019, . [STD94] Internet Standard 94, . At the time of writing, this STD comprises the following: Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949, DOI 10.17487/RFC8949, December 2020, . 7.2. Informative References [I-D.bormann-cbor-det] Bormann, C., "CBOR: On Deterministic Encoding and Representation", Work in Progress, Internet-Draft, draft- bormann-cbor-det-04, 21 January 2025, . [I-D.bormann-cbor-numbers] Bormann, C., "On Numbers in CBOR", Work in Progress, Internet-Draft, draft-bormann-cbor-numbers-01, 8 January 2025, . [I-D.bormann-dispatch-modern-network-unicode] Bormann, C., "Modern Network Unicode", Work in Progress, Internet-Draft, draft-bormann-dispatch-modern-network- unicode-05, 30 August 2024, . [I-D.mcnally-deterministic-cbor] McNally, W., Allen, C., Bormann, C., and L. Lundblade, "dCBOR: A Deterministic CBOR Application Profile", Work in Bormann Expires 14 August 2025 [Page 11] Internet-Draft CBOR CDE February 2025 Progress, Internet-Draft, draft-mcnally-deterministic- cbor-12, 7 February 2025, . [RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, May 2018, . [RFC9581] Bormann, C., Gamari, B., and H. Birkholz, "Concise Binary Object Representation (CBOR) Tags for Time, Duration, and Period", RFC 9581, DOI 10.17487/RFC9581, August 2024, . [RFC9679] Isobe, K., Tschofenig, H., and O. Steele, "CBOR Object Signing and Encryption (COSE) Key Thumbprint", RFC 9679, DOI 10.17487/RFC9679, December 2024, . [STD96] Internet Standard 96, . At the time of writing, this STD comprises the following: Schaad, J., "CBOR Object Signing and Encryption (COSE): Structures and Process", STD 96, RFC 9052, DOI 10.17487/RFC9052, August 2022, . Schaad, J., "CBOR Object Signing and Encryption (COSE): Countersignatures", STD 96, RFC 9338, DOI 10.17487/RFC9338, December 2022, . [UAX-15] "Unicode Normalization Forms", Unicode Standard Annex, . Appendix A. 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. 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 Bormann Expires 14 August 2025 [Page 12] Internet-Draft CBOR CDE February 2025 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). For instance, CWT defines an application data type "NumericDate" which (as an application-level rule) is formed by "unwrapping" tag 1 (see Sections 2 and 5 of [RFC8392]). CWT does stop short of using deterministic encoding. A hypothetical deterministic variant of CWT would need to make an additional ALDR rule for NumericDate, as the definition of tag 1 allows both integer and floating point numbers (Section 3.4.2 of RFC 8949 [STD94]), which allows multiple application-level representations of integral numbers. These application rules may choose to only ever use integers, or to always use integers when the numeric value can be represented as such without loss of information, or to always use floating point numbers, or some of these for some application data and different ones for other application data. 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). As an example, [RFC9679] is intended to derive a (deterministic) thumbprint from a COSE key [STD96]. Section 4 of [RFC9679] provides the rules that are used to construct a deterministic application- level representation (ALDR rules). Only certain data from a COSE key are selected to be included in that ALDR, and, where the COSE can choose multiple representations of semantically equivalent application data, the ALDR rules choose one of them, potentially requiring a conversion (Section 4.2 of [RFC9679]): | Note: [RFC9052] supports both compressed and uncompressed point | representations. For interoperability, implementations adhering | to this specification MUST use the uncompressed point | representation. Therefore, the y-coordinate is expressed as a | bstr. If an implementation uses the compressed point | representation, it MUST first convert it to the uncompressed form | for the purpose of thumbprint calculation. Bormann Expires 14 August 2025 [Page 13] Internet-Draft CBOR CDE February 2025 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. An early example of a separate document is the dCBOR specification [I-D.mcnally-deterministic-cbor]. dCBOR specifies the use of CDE together with some application-level rules, i.e., an ALDR ruleset, such as a requirement for all text strings to be in Unicode Normalization Form C (NFC) [UAX-15] — this specific requirement is an example for an _exclusion_ of non-NFC data at the application level, and it invites implementing a _reduction_ by routine normalization of text strings. 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 decoders", see also Appendix B). 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). Bormann Expires 14 August 2025 [Page 14] Internet-Draft CBOR CDE February 2025 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 B. 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 and Decoders as well as CDE Encoders and 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 decoders" specifically advertised as supporting CDE) are not required to check for preferred serialization or CDE and reject inputs that do not fulfill their 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 Bormann Expires 14 August 2025 [Page 15] Internet-Draft CBOR CDE February 2025 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 for proper CDE encoding is to re-encode the decoded data and check for bit-to-bit equality with the original input. B.1. Preferred Serialization In the following, the abbreviation "ai" will be used for the 5-bit additional information field in the first byte of an encoded CBOR data item, which follows the 3-bit field for the major type. B.1.1. Preferred Serialization Encoders 1. Shortest-form encoding of the argument MUST be used for all major types. Major type 7 is used for floating-point and simple values; floating point values have its specific rules for how the shortest form is derived for the argument. The shortest form encoding for any argument that is not a floating point value is: * 0 to 23 and -1 to -24 MUST be encoded in the same byte as the major type. * 24 to 255 and -25 to -256 MUST be encoded only with an additional byte (ai = 0x18). * 256 to 65535 and -257 to -65536 MUST be encoded only with an additional two bytes (ai = 0x19). * 65536 to 4294967295 and -65537 to -4294967296 MUST be encoded only with an additional four bytes (ai = 0x1a). 2. If floating-point numbers are emitted, the following apply: * The length of the argument indicates half (binary16, ai = 0x19), single (binary32, ai = 0x1a) and double (binary64, ai = 0x1b) precision encoding. If multiple of these encodings preserve the precision of the value to be encoded, only the shortest form of these MUST be emitted. That is, encoders MUST support half-precision and single-precision floating point. * [IEEE754] Infinites and NaNs, and thus NaN payloads, MUST be supported, to the extent possible on the platform. Bormann Expires 14 August 2025 [Page 16] Internet-Draft CBOR CDE February 2025 As with all floating point numbers, Infinites and NaNs MUST be encoded in the shortest of double, single or half precision that preserves the value: - Positive and negative infinity and zero MUST be represented in half-precision floating point. - For NaNs, the value to be preserved includes the sign bit, the quiet bit, and the NaN payload (whether zero or non- zero). The shortest form is obtained by removing the rightmost N bits of the payload, where N is the difference in the number of bits in the significand (mantissa representation) between the original format and the shortest format. This trimming is performed only (preserves the value only) if all the rightmost bits removed are zero. (This will always represent a double or single quiet NaN with a zero NaN payload in a half- precision quiet NaN.) 3. If tags 2 and 3 are supported, the following apply: * Positive integers from 0 to 2^64 - 1 MUST be encoded as a type 0 integer. * Negative integers from -(2^64) to -1 MUST be encoded as a type 1 integer. * Leading zeros MUST NOT be present in the byte string content of tag 2 and 3. (This also applies to the use of tags 2 and 3 within other tags, such as 4 or 5.) B.1.2. Preferred Serialization Decoders There are no special requirements that CBOR decoders need to meet to be a Preferred Serialization Decoder. Partial decoder implementations need to pay attention to at least the following requirements: 1. Decoders MUST accept shortest-form encoded arguments (see Section 3 of RFC 8949 [STD94]). 2. If arrays or maps are supported, definite-length arrays or maps MUST be accepted. 3. If text or byte strings are supported, definite-length text or byte strings MUST be accepted. Bormann Expires 14 August 2025 [Page 17] Internet-Draft CBOR CDE February 2025 4. If floating-point numbers are supported, the following apply: * Half-precision values MUST be accepted. * Double- and single-precision values SHOULD be accepted; leaving these out is only foreseen for decoders that need to work in exceptionally constrained environments. * If double-precision values are accepted, single-precision values MUST be accepted. * Infinites and NaNs, and thus NaN payloads, MUST be accepted and presented to the application (not necessarily in the platform number format, if that doesn't support those values). 5. If big numbers (tags 2 and 3) are supported, type 0 and type 1 integers MUST be accepted where a tag 2 or 3 would be accepted. Leading zero bytes in the tag content of a tag 2 or 3 MUST be ignored. B.2. Basic Serialization Basic Serialization further restricts Preferred Serialization by not using indefinite length encoding. A CBOR encoder can choose to employ Basic Serialization in order to reduce the variability that needs to be handled by decoders, potentially maximizing interoperability with partial (e.g., constrained) CBOR decoder implementations. B.2.1. Basic Serialization Encoders The Basic Serialization Encoder requirements are identical to the Preferred Serialization Encoder requirements, with the following additions: 1. If maps or arrays are emitted, they MUST use definite-length encoding (never indefinite-length). 2. If text or byte strings are emitted, they MUST use definite- length encoding (never indefinite-length). B.2.2. Basic Serialization Decoders The Basic Serialization Decoder requirements are identical to the Preferred Serialization Decoder requirements. B.3. CDE Bormann Expires 14 August 2025 [Page 18] Internet-Draft CBOR CDE February 2025 B.3.1. CDE Encoders 1. CDE encoders MUST only emit CBOR fulfilling the basic serialization rules (Appendix B.2.1). 2. CDE encoders MUST sort maps by the CBOR representation of the map key. The sorting is byte-wise lexicographic order of the encoded map key data items. 3. CDE encoders MUST generate CBOR that fulfills basic validity (Section 5.3.1 of RFC 8949 [STD94]). Note that this includes not emitting duplicate keys in a major type 5 map as well as emitting only valid UTF-8 in major type 3 text strings. Note also that CDE does NOT include a requirement for Unicode normalization [UAX-15]; Appendix C of [I-D.bormann-dispatch-modern-network-unicode] contains some rationale that went into not requiring routine use of Unicode normalization processes. B.3.2. CDE Decoders The term "CDE Decoder" is a shorthand for a CBOR decoder that advertises _supporting_ CDE (see the start of this appendix). 1. CDE decoders MUST follow the rules for preferred (and thus basic) serialization decoders (Appendix B.1.2). 2. CDE decoders MUST check for ordering map keys and for basic validity of the CBOR encoding (see Section 5.3.1 of RFC 8949 [STD94], which includes a check against duplicate map keys and invalid UTF-8). To be called a CDE decoder, it MUST NOT present to the application a decoded data item that fails one of these checks (except maybe via special diagnostic channels with no potential for confusion with a correctly CDE-decoded data item). List of Tables 1. Constraints on the Serialization of CBOR (Table 1) 2. New control operators to be registered (Table 2) Bormann Expires 14 August 2025 [Page 19] Internet-Draft CBOR CDE February 2025 Acknowledgments An earlier 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 ALDR rules/rulesets on top of that. Contributors Laurence Lundblade Security Theory LLC Email: lgl@securitytheory.com Laurence provided most of the text that became Appendix B. Author's Address Carsten Bormann Universität Bremen TZI Postfach 330440 D-28359 Bremen Germany Phone: +49-421-218-63921 Email: cabo@tzi.org Bormann Expires 14 August 2025 [Page 20]