Concise Binary Object Representation (CBOR) Tags for Object Identifiers
Extracted elements (24)
The BER encoding format was chosen for OIDs because staying close to ASN.1 BER makes back-and-forth translation easy, avoids inventing a third serialization form (alongside dotted decimal and BER), and aligns with existing expectations about OID encoding cost. A more efficient encoding could have been chosen otherwise.
Three separate tags are defined (111, 110, 112) rather than one because the semantics of absolute and relative OIDs differ, and because self-assigned numbers under '1.3.6.1.4.1' (Private Enterprise Numbers) are extremely common, adding 5 fixed bytes to each encoded OID; tag 112 eliminates this overhead.
For OIDs under '1.3.6.1.4.1', both tag 111 and tag 112 representations are valid, but tag 112 is the preferred serialization. Decoders implementing deterministic encoding MUST accept tag 112 as equivalent to tag 111 with the prefix h'2b06010401' in the enclosed byte string.
While X.680 restricts RELATIVE-OID values to having at least one arc, this specification permits empty relative object identifiers tagged with tag 110. Applications may still exclude empty relative OIDs through their own semantics.
A byte string tagged with 111, 110, or 112 MUST be syntactically valid contents for a BER representation of an object identifier, conforming to X.690 Clauses 8.19 or 8.20 as applicable. A tag with content not conforming to the applicable regular expression is invalid.
For OIDs with a prefix of '1.3.6.1.4.1', tag 112 is the preferred serialization over tag 111; it is five bytes shorter. The Core Deterministic Encoding Requirements of RFC 8949 Section 4.2.1 therefore require use of tag 112 wherever applicable.
It is RECOMMENDED that definite length encoding (per RFC 8949 Section 3.2.3) be used for byte strings used as tag content for OID tags, to facilitate searching for specific object ID values.
The first byte of each SDNV within the tagged byte string MUST NOT be 0x80, ensuring integer values are expressed in their shortest form with no leading zeros in base-128 arithmetic.
The last byte of the tagged byte string MUST NOT have its most significant bit set, as this would indicate an incomplete final integer value.
Where tag factoring with tag 111 is used, individual OIDs with the '1.3.6.1.4.1' prefix may still be encoded with tag 112 as nested tags, which remains the preferred serialization. Application protocols define where tag factoring is used and may impose deterministic encoding requirements.
OID tags can be applied to CBOR arrays and maps for tag factoring: when the tag content is an array, the tag is imputed to all byte string, array, or map elements; when the content is a map, the tag is imputed to all byte string, array, or map keys. Values in maps are unaffected.
Recommended CDDL type names for OID tags are: 'oid = #6.111(bstr)' for absolute OIDs, 'roid = #6.110(bstr)' for relative OIDs, and 'pen = #6.112(bstr)' for Private Enterprise Number-relative OIDs.
Tag number 110 is used to tag a CBOR byte string, array, or map as the BER encoding of a relative object identifier (RELATIVE-OID). It can also tag a byte string containing a sequence of zero or more SDNVs per X.690 Clause 8.20.
Tag number 111 is used to tag a CBOR byte string, array, or map as the BER encoding of an absolute object identifier (OID). The byte string content must be the value part of a BER-encoded OID per X.690 Clause 8.19.
Tag number 112 is structurally like tag 110 but is understood to be relative to '1.3.6.1.4.1' (IANA Private Enterprise Number OID). The semantics of the result are that of an absolute OID, saving five bytes for OIDs under the enterprise arc.
The CDDL control operator '.oid' is like '.sdnvseq' but includes the X*40+Y translation for the first two arcs of absolute OIDs. Example: 'bytes .oid [2, 5, 4, 6]' specifies the country attribute type OID.
The CDDL control operator '.sdnv' constrains a byte string target to be the SDNV (BER encoding) of a single unsigned integer matching the control type. The operator '.sdnvseq' constrains the byte string to be a sequence of SDNVs decoding to an array of unsigned integers.
IANA has assigned three new CBOR tag numbers in the 1+1 byte space (24..255) of the CBOR Tags registry: tag 111 (absolute OID, BER encoding), tag 110 (relative OID / SDNV sequence, BER encoding), and tag 112 (OID relative to 1.3.6.1.4.1, BER encoding). All apply to byte string, array, or map data items.
IANA has assigned three new entries in the CDDL Control Operators registry: '.sdnv', '.sdnvseq', and '.oid', all with RFC 9090 as the specification reference.
An attacker may trick an application into treating a byte string inside a tag-factored data item as falling under an OID tag when it was not intended to, causing the application to emit data with unintended semantics. Applications must be restrictive about what data items they apply tag factoring to.
It is strongly NOT RECOMMENDED to perform any structural processing of OIDs (such as converting to dotted notation and back) unless absolutely necessary. OIDs and relative OIDs can always be treated as opaque byte strings; integer values are unlimited in range and conversion errors can introduce vulnerabilities.
The BER encodings in X.690 Clauses 8.19 and 8.20 MUST be followed precisely. Failure to validate the requirements from Section 2.1 may allow an attacker to subvert a checking process by submitting alternative representations that are decoded differently by a protected decoder.
OID tag content is a concatenation of zero or more SDNV values. Each SDNV is a sequence of one or more bytes with their MSB set, except for the last byte. For absolute OIDs, the first two arcs X and Y are encoded as the single value X*40+Y.
The SHA-256 OID (2.16.840.1.101.3.4.2.1) encodes in CBOR as: D8 6F (tag 111), 49 (9-byte byte string), 60 86 48 01 65 03 04 02 01 — the same 9-byte value part as the BER encoding.