RFC 9090
Concise Binary Object Representation (CBOR) Tags for Object Identifiers
Concise Binary Object Representation (CBOR) Tags for Object Identifiers 🎀
RFC 9090 ✨ | Author: C. Bormann, Universität Bremen TZI | Category: Standards Track | Date: July 2021 | ISSN: 2070-1721
Okay bestie, this is the spec for tagging object identifiers (OIDs) in CBOR. It's a Standards Track doc, so it's official IETF consensus, not just someone's opinion 💅 It doesn't obsolete or update any other RFCs, so you can read it on its own. Let's go!! 🦋
Abstract
So CBOR (that's [RFC8949]) is a data format with some seriously iconic goals: super small code size, pretty small message size, and it can grow over time without needing version negotiation 🌸
This document defines CBOR tags for object identifiers (OIDs) and is the reference document for the IANA registration of the CBOR tags so defined. 📚
Status of This Memo
This is an Internet Standards Track document. 🏆
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). If you want more info on Internet Standards, check out Section 2 of RFC 7841.
For the current status of this document, any errata, and how to send feedback, go to https://www.rfc-editor.org/info/rfc9090. 🔗
Copyright Notice
Copyright (c) 2021 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 actually read these, ngl, because they spell out your rights and restrictions for this document. Code Components extracted from this document must include Simplified BSD License text 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
1.1. Terminology
2. Object Identifiers
2.1. Requirements on the Byte String Being Tagged
2.2. Preferred Serialization Considerations
2.3. Discussion
3. Basic Examples
3.1. Encoding of the SHA-256 OID
3.2. Encoding of a MIB Relative OID
4. Tag Factoring with Arrays and Maps
4.1. Preferred Serialization Considerations
4.2. Tag Factoring Example: X.500 Distinguished Name
5. CDDL Control Operators
6. CDDL Type Names
7. IANA Considerations
7.1. CBOR Tags
7.2. CDDL Control Operators
8. Security Considerations
9. References
9.1. Normative References
9.2. Informative References
Acknowledgments
Contributors
Author's Address1. Introduction ✨
Okay so CBOR ([RFC8949]) lets you swap structured data around without needing a schema you agreed on ahead of time. 🫶 [RFC8949] gives you a basic set of data types, plus a tagging mechanism that lets you add new data types through an IANA registry. It's giving extensibility!!
This document defines CBOR tags for object identifiers (OIDs) [X.660], which tons of IETF protocols carry around. The ASN.1 Basic Encoding Rules (BER) [X.690] define the binary encodings for both absolute object identifiers and relative object identifiers. The contents of those encodings (the "value" part of BER's type-length-value structure) can be stuffed into a CBOR byte string. This document defines two CBOR tags for the two kinds of ASN.1 object identifiers encoded that way, plus a third one for a common optimization 🌈 The tags can also be applied to arrays and maps, so you can tag every element of an array or every key of a map in one go. This document is the reference for the IANA registration of the tags defined here. 💖
1.1. Terminology
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 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 🔥
The terminology of [RFC8949] applies. Specifically, "byte" is used in its now-customary sense as a synonym for "octet". 🍓 The verb "to tag (something)" means building a CBOR tag, with the object (something) as the tag content and a tag number mentioned elsewhere in the sentence (for example, in a "with" clause, or by the shorthand "an NNN tag" for "a tag with tag number NNN"). The term "SDNV" (Self-Delimiting Numeric Value) is used as defined in [RFC6256], with the extra restriction in Section 2.1 (no leading zeros). 💅
2. Object Identifiers 🌸
The International Object Identifier tree [X.660] is a hierarchically managed space of identifiers. Each one is uniquely represented as a sequence of unsigned integer values [X.680]. (In [X.660] these integer values are called "primary integer values", because they can come with (not necessarily unambiguous) secondary identifiers. We ignore those and just say "integer values" here, sometimes pointing out that they're unsigned. We also use "arc" when we're focusing on the edge of the tree labeled by such an integer value, and for a "long arc", meaning a (sub)sequence of such integer values.)
Those sequences could easily be stored in CBOR arrays of unsigned integers, but a more compact representation is often possible by using the widely used BER representation of object identifiers. That representation may also be easier for other software that works with object identifiers to process. 🧁
BER represents the sequence of unsigned integers by concatenating self-delimiting representations [RFC6256] of each integer value, in order. ✨
ASN.1 has two types. Absolute object identifiers (ASN.1 type "OBJECT IDENTIFIER") begin at a root arc ([X.660], Clause 3.5.21). Relative object identifiers (ASN.1 type "RELATIVE-OID") begin relative to some object identifier known from context ([X.680], Clause 3.8.63). Here's the special optimization: BER squishes the first two integers in an absolute object identifier into one numeric identifier. It can do that because the first arc only has three integer values (0, 1, and 2), and the second arcs under 0 and 1 are limited to integer values between 0 and 39. (The root arc "joint-iso-itu-t(2)" has no such limit on its second arc.) If X and Y are the first two integer values, the single integer value that actually gets encoded is:
X * 40 + YDecoding does the inverse transformation, again using those known ranges of X and Y. 🧩
Absolute and relative object identifiers have different semantics. Companies very often use self-assigned numbers under the arc "1.3.6.1.4.1" (IANA Private Enterprise Number OID [IANA.enterprise-numbers]), and that prefix adds 5 fixed bytes to an encoded OID value. So this specification defines three tags, which are collectively called the "OID tags" here: 🦋
- Tag number 111: Used to tag a byte string as the BER encoding [X.690] of an absolute object identifier (simply "object identifier" or "OID").
- Tag number 110: Used to tag a byte string as the BER encoding [X.690] of a relative object identifier (also called "relative OID"). Since the encoding of each number is the same as for Self-Delimiting Numeric Values (SDNVs) [RFC6256], this tag can also be used to tag a byte string that contains a sequence of zero or more SDNVs. (Or you can make a more application-specific tag for that job.)
- Tag number 112: Structurally like tag 110, but understood to be relative to "1.3.6.1.4.1" (IANA Private Enterprise Number OID [IANA.enterprise-numbers]). So the semantics of the result are those of an absolute object identifier. 👑
2.1. Requirements on the Byte String Being Tagged 📏
To form a valid tag, a byte string tagged with 111, 110, or 112 MUST be syntactically valid contents (the value part) for a BER representation of an object identifier (see Table 1):
+============+====================+
| Tag number | Section of [X.690] |
+============+====================+
| 111 | 8.19 |
+------------+--------------------+
| 110 | 8.20 |
+------------+--------------------+
| 112 | 8.20 |
+------------+--------------------+
Table 1: Tag Number and
Section of X.690 Governing Tag
ContentThis is a concatenation of zero or more SDNV values. Each SDNV value is a sequence of one or more bytes where all of them have their most significant bit set, except the last byte, which has it unset. Also, the first byte of each SDNV cannot be a leading zero in SDNV's base-128 arithmetic, so it cannot take the value 0x80 (bullet (c) in Section 8.1.2.4.2 of [X.690]). 🙈
In other words:
- The byte string's first byte, and any byte that follows a byte that has the most significant bit unset, MUST NOT be
0x80. (This requirement means integer values have to be written in their shortest form, with no leading zeroes.) - The byte string's last byte MUST NOT have the most significant bit set. (This requirement rules out an incomplete final integer value.)
If either of these invalid conditions shows up, the tag is invalid. 💀
[X.680] restricts RELATIVE-OID values to having at least one arc, so their encoding would have at least one SDNV. This specification does allow empty relative object identifiers, though. Application semantics may still exclude them. 🌈
To make it easier to search for specific object ID values, it is RECOMMENDED that definite length encoding (see Section 3.2.3 of [RFC8949]) be used for the byte strings that serve as tag content for these tags. 🔍
The valid set of byte strings can also be written as regular expressions on bytes. The notation isn't a specific one, but it looks a lot like Perl Compatible Regular Expressions [PCRE]. Unlike typical regular expressions that work on character sequences, these regular expressions take bytes as their domain, so you can apply them directly to CBOR byte strings. 🧠
For byte strings with tag 111:
"/^(([\x81-\xFF][\x80-\xFF]*)?[\x00-\x7F])+$/"For byte strings with tags 110 or 112:
"/^(([\x81-\xFF][\x80-\xFF]*)?[\x00-\x7F])*$/"A tag whose tagged content doesn't match the applicable regular expression is invalid. ❌
2.2. Preferred Serialization Considerations 💖
For an absolute OID with a prefix of "1.3.6.1.4.1", both the 111 and 112 tags are applicable. The representation with 112 is five bytes shorter, because it leaves out the prefix h'2b06010401' from the enclosed byte string. This specification makes that shorter representation the preferred serialization (see Sections 3.4 and 4.1 of [RFC8949]). Note that this also means the Core Deterministic Encoding Requirements (Section 4.2.1 of [RFC8949]) require using 112 tags instead of 111 tags wherever that's possible. 🎀
2.3. Discussion
Keeping this close to how ASN.1 BER encodes object identifiers makes translating back and forth super easy 🦋. Otherwise, we'd have picked a more efficient encoding ✨. IETF protocols already write object identifiers in dotted decimal form or BER form, so there's a real perk in not inventing a third form 💅. Plus, people's expectations about what encoding OIDs costs are based on BER, and a different encoding might not match those vibes 🙈. If you want more info about an OID, you can check out lookup services like the OID Resolution Service (ORS) [X.672] and the OID Repository [OID-INFO] 🔍.
3. Basic Examples 🧚
This section has simple examples of an absolute OID and a relative OID. They use tag numbers 111 and 110, in that order 🎀.
3.1. Encoding of the SHA-256 OID
ASN.1 Value Notation:
{ joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101)
csor(3) nistalgorithm(4) hashalgs(2) sha256(1) }Dotted Decimal Notation: 2.16.840.1.101.3.4.2.1 💖
06 # UNIVERSAL TAG 6
09 # 9 bytes, primitive
60 86 48 01 65 03 04 02 01 # X.690 Clause 8.19
# | 840 1 | 3 4 2 1 show component encoding
# 2.16 101
Figure 1: SHA-256 OID in BERD8 6F # tag(111)
49 # 0b010_01001: mt 2, 9 bytes
60 86 48 01 65 03 04 02 01 # X.690 Clause 8.19
Figure 2: SHA-256 OID in CBOR3.2. Encoding of a MIB Relative OID
Say we've got some OID (like "lowpanMib", which we're assuming is "1.3.6.1.2.1.226" [RFC7388]) 🌸, and we tack this on:
ASN.1 Value Notation:
{ lowpanObjects(1) lowpanStats(1) lowpanOutTransmits(29) }Dotted Decimal Notation: .1.1.29 ✨
0D # UNIVERSAL TAG 13
03 # 3 bytes, primitive
01 01 1D # X.690 Clause 8.20
# 1 1 29 show component encoding
Figure 3: MIB Relative Object Identifier in BERD8 6E # tag(110)
43 # 0b010_00011: mt 2 (bstr), 3 bytes
01 01 1D # X.690 Clause 8.20
Figure 4: MIB Relative Object Identifier in CBORNgl, this relative OID saves you seven bytes compared to the full OID encoding 🤌.
4. Tag Factoring with Arrays and Maps 🫶
OID tags can have byte strings as their tag content (like we just covered) 💜, but they can also hold CBOR arrays and maps. The vibe here is that the tag gets factored out of each individual item in the container and gets slapped onto the array or map instead 🎀.
When the tag content of an OID tag is an array, the tag gets imputed to every element of that array that's a byte string, array, or map 👑. Anything else, including text strings or tags, is unaffected 🙈. For example, if the tag content of a 111 tag is an array, then every element that's a byte string is an OID, and every element that's an array or map gets treated the same way we're describing here 🦋.
When the tag content of an OID tag is a map, a tag with the same tag number gets imputed to all keys in the map that are byte strings, arrays, or maps 🌈. Again, keys of other major types don't get touched 💅. Also, the values in the map? Nothing happens to them 🧚.
Because of all these rules, tag factoring works in nested arrays and maps too 🔥. For example, you can write a 3-dimensional array of OIDs using one 111 tag wrapped around an array of arrays of arrays of byte strings. Every one of those byte strings then counts as an OID 😭✨.
4.1. Preferred Serialization Considerations
When you're using tag factoring with tag number 111, some OIDs inside the tag can be encoded in a shorter way by using tag number 112 instead of a plain byte string 💖. That's still the preferred serialization (see also Section 2.2) 👑. That said, this spec doesn't make using tag factoring, or skipping it, a preferred serialization. Application protocols get to decide where tag factoring goes, and they'll need to spell that out if they have deterministic encoding requirements 🫶.
4.2. Tag Factoring Example: X.500 Distinguished Name
Let's look at this X.500 distinguished name 👀:
+==============================+=============+
| Attribute Types | Attribute |
| | Values |
+==============================+=============+
| c (2.5.4.6) | US |
+------------------------------+-------------+
| l (2.5.4.7) | Los Angeles |
| s (2.5.4.8) | CA |
| postalCode (2.5.4.17) | 90013 |
+------------------------------+-------------+
| street (2.5.4.9) | 532 S Olive |
| | St |
+------------------------------+-------------+
| businessCategory (2.5.4.15) | Public Park |
| buildingName | Pershing |
| (0.9.2342.19200300.100.1.48) | Square |
+------------------------------+-------------+
Table 2: Example X.500 Distinguished NameTable 2 has four "relative distinguished names" (RDNs) 🌷. The first one (country) and the third one (street) each have a single value. The second and fourth RDNs are multivalued 💜.
The same thing in CBOR diagnostic notation (Section 8 of [RFC8949]) and in CBOR looks like this ✨:
111([{ h'550406': "US" },
{ h'550407': "Los Angeles",
h'550408': "CA",
h'550411': "90013" },
{ h'550409': "532 S Olive St" },
{ h'55040f': "Public Park",
h'0992268993f22c640130': "Pershing Square" }])
Figure 5: Distinguished Name in CBOR Diagnostic Notationd8 6f # tag(111)
84 # array(4)
a1 # map(1)
43 550406 # 2.5.4.6 (4)
62 # text(2)
5553 # "US"
a3 # map(3)
43 550407 # 2.5.4.7 (4)
6b # text(11)
4c6f7320416e67656c6573 # "Los Angeles"
43 550408 # 2.5.4.8 (4)
62 # text(2)
4341 # "CA"
43 550411 # 2.5.4.17 (4)
65 # text(5)
3930303133 # "90013"
a1 # map(1)
43 550409 # 2.5.4.9 (4)
6e # text(14)
3533322053204f6c697665205374 # "532 S Olive St"
a2 # map(2)
43 55040f # 2.5.4.15 (4)
6b # text(11)
5075626c6963205061726b # "Public Park"
4a 0992268993f22c640130 # 0.9.2342.19200300.100.1.48 (11)
6f # text(15)
5065727368696e6720537175617265 # "Pershing Square"
Figure 6: Distinguished Name in CBOR (109 Bytes)(This example assumes that all attribute values are UTF-8 strings, or can be represented as UTF-8 strings without losing any information 🫶.)
5. CDDL Control Operators 🎀
Concise Data Definition Language (CDDL) specifications [RFC8610] might want to specify SDNVs or SDNV sequences (the ones defined for the tag content of tag 110) 💅. This document introduces two new control operators that can be applied to a target value that's a byte string, plus a third one 🔥:
.sdnv, with a control type that contains unsigned integers. The byte string is specified to be encoded as an SDNV (BER encoding) [RFC6256] for the values matching the control type 💖..sdnvseq, with a control type that contains arrays of unsigned integers. The byte string is specified to be encoded as a sequence of SDNVs (BER encoding) [RFC6256] that decodes to an array of unsigned integers matching the control type 🌸..oid, which is like.sdnvseq, except that the X*40+Y translation for absolute OIDs is included (see Figure 8) ✨.
Figure 7 shows .sdnvseq in action for part of a structure using OIDs (the kind you could use in Figure 6), and Figure 8 shows the same thing with the .oid operator 👑.
country-rdn = {country-oid => country-value}
country-oid = bytes .sdnvseq [85, 4, 6]
country-value = text .size 2
Figure 7: Using .sdnvseqcountry-rdn = {country-oid => country-value}
country-oid = bytes .oid [2, 5, 4, 6]
country-value = text .size 2
Figure 8: Using .oidAlso, the control type doesn't have to be a literal 🧚. For example, bytes .oid [2, 5, 4, *uint] matches all OIDs inside the OID arc "2.5.4", which is "attributeType" 🌈.
6. CDDL Type Names 💜
When you're working with CDDL, the type names in Figure 9 are recommended 🫶:
oid = #6.111(bstr)
roid = #6.110(bstr)
pen = #6.112(bstr)
Figure 9: Recommended Type Names for CDDL7. IANA Considerations 🌈
7.1. CBOR Tags
IANA has assigned the CBOR tag numbers in Table 3 from the 1+1 byte space (24..255) of the "CBOR Tags" registry [IANA.cbor-tags] 🦋, with this document as the specification reference 💖.
+=====+===============+============================+===========+
| Tag | Data Item | Semantics | Reference |
+=====+===============+============================+===========+
| 111 | byte string, | object identifier (BER | RFC 9090 |
| | array, or map | encoding) | |
+-----+---------------+----------------------------+-----------+
| 110 | byte string, | relative object identifier | RFC 9090 |
| | array, or map | (BER encoding); SDNV | |
| | | [RFC6256] sequence | |
+-----+---------------+----------------------------+-----------+
| 112 | byte string, | object identifier (BER | RFC 9090 |
| | array, or map | encoding), relative to | |
| | | 1.3.6.1.4.1 | |
+-----+---------------+----------------------------+-----------+
Table 3: New Tag Numbers7.2. CDDL Control Operators
IANA has assigned the CDDL control operators in Table 4 in the "CDDL Control Operators" registry [IANA.cddl] 🎀, with this document as the specification reference ✨.
+==========+===========+
| Name | Reference |
+==========+===========+
| .sdnv | RFC 9090 |
+----------+-----------+
| .sdnvseq | RFC 9090 |
+----------+-----------+
| .oid | RFC 9090 |
+----------+-----------+
Table 4: New CDDL
Control Operators8. Security Considerations 🔐✨
okay bestie, security is serious business, so buckle up 😭. First up, the security considerations of [RFC8949] apply, so everything CBOR already warns you about still counts here. no skipping that part 🙈
The encodings in Clauses 8.19 and 8.20 of [X.690] are super compact and unambiguous, but they MUST be followed precisely or you're asking for trouble 💀. Especially the requirements in Section 2.1 of this document. If you don't follow them, an attacker can slip in alternative representations. Then a checking process approves one version, but a later decoder (the one the check was supposed to protect) reads it as the original, or even as something completely different. Not it. 🙅♀️
Quick warning: an attacker can exploit the gap between what gets checked and what gets decoded. Keep the representations consistent and you're safe 🔥
OIDs and relative OIDs can always be treated as opaque byte strings, which is honestly the iconic move 💅. You don't need to understand how they were built. Apart from checking the structure requirements, it is strongly NOT RECOMMENDED to process them in any other way (like converting to dotted notation and back) unless it is absolutely necessary. If you do translate them into other representations, the usual security considerations for non-trivial representation conversions apply. And remember, the integer values are unlimited in range, so don't assume anything fits in a small box 🌈.
Last but definitely not least: an attacker might trick an application into using a byte string inside a tag-factored data item, even though that byte string was never meant to fall under one of the tags defined here 😱. That could make the application emit data with meanings nobody intended. So applications need to be restrictive about which data items they apply tag factoring to. Be picky, bestie. 👑
9. References 📚
Here's the full reference list, copied exactly so nothing gets lost 🎀.
9.1. Normative References
[IANA.cbor-tags]
IANA, "Concise Binary Object Representation (CBOR) Tags",
<https://www.iana.org/assignments/cbor-tags>.
[IANA.cddl]
IANA, "Concise Data Definition Language (CDDL)",
<https://www.iana.org/assignments/cddl>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC6256] Eddy, W. and E. Davies, "Using Self-Delimiting Numeric
Values in Protocols", RFC 6256, DOI 10.17487/RFC6256, May
2011, <https://www.rfc-editor.org/info/rfc6256>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[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, <https://www.rfc-editor.org/info/rfc8610>.
[RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", STD 94, RFC 8949,
DOI 10.17487/RFC8949, December 2020,
<https://www.rfc-editor.org/info/rfc8949>.
[X.660] ITU-T, "Information technology - Procedures for the
operation of object identifier registration authorities:
General procedures and top arcs of the international
object identifier tree", ITU-T Recommendation X.660, July
2011, <https://www.itu.int/rec/T-REC-X.660>.
[X.680] ITU-T, "Information technology - Abstract Syntax Notation
One (ASN.1): Specification of basic notation", ITU-T
Recommendation X.680, August 2015,
<https://www.itu.int/rec/T-REC-X.680>.
[X.690] ITU-T, "Information technology - ASN.1 encoding rules:
Specification of Basic Encoding Rules (BER), Canonical
Encoding Rules (CER) and Distinguished Encoding Rules
(DER)", ITU-T Recommendation X.690, August 2015,
<https://www.itu.int/rec/T-REC-X.690>.9.2. Informative References
[IANA.enterprise-numbers]
IANA, "Private Enterprise Numbers",
<https://www.iana.org/assignments/enterprise-numbers>.
[OID-INFO] Orange SA, "Object Identifier (OID) Repository",
<http://www.oid-info.com/>.
[PCRE] "PCRE - Perl Compatible Regular Expressions",
<http://www.pcre.org/>.
[RFC7388] Schoenwaelder, J., Sehgal, A., Tsou, T., and C. Zhou,
"Definition of Managed Objects for IPv6 over Low-Power
Wireless Personal Area Networks (6LoWPANs)", RFC 7388,
DOI 10.17487/RFC7388, October 2014,
<https://www.rfc-editor.org/info/rfc7388>.
[X.672] ITU-T, "Information technology - Open systems
interconnection - Object identifier resolution system
(ORS)", ITU-T Recommendation X.672, August 2010,
<https://www.itu.int/rec/T-REC-X.672>.Acknowledgments 🫶
Huge thanks to Sean Leonard, who kicked off this work in 2014 with a very elaborate proposal 🧚. Jim Schaad gave a significant review of the document 💜. And Rob Wilton's IESG review is the reason we added the preferred serialization considerations 🌸. Iconic team energy, honestly.
Contributors 🌈
Sean Leonard
Penango, Inc.
5900 Wilshire Boulevard
21st Floor
Los Angeles, CA 90036
United States of America
Email: dev+ietf@seantek.comAuthor's Address 🦋
Carsten Bormann
Universität Bremen TZI
Postfach 330440
D-28359 Bremen
Germany
Phone: +49-421-218-63921
Email: cabo@tzi.org📦 where this page comes from
- ietf: rfc9090 2021-07
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms