| RFC 9090 | CBOR Tags for OIDs | July 2021 |
| Bormann | Standards Track | [Page] |
The Concise Binary Object Representation (CBOR), defined in RFC 8949, is a dataformat whose design goals include the possibility of extremely smallcode size, fairly small message size, and extensibility without theneed for version negotiation.¶
This document defines CBOR tags forobject identifiers (OIDs) and isthe reference document for the IANA registration of the CBOR tagsso defined.¶
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). Further information on Internet Standards is available in Section 2 of RFC 7841.¶
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained athttps://www.rfc-editor.org/info/rfc9090.¶
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 review these documents carefully, as they describe your rights and restrictions with respect to 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.¶
The Concise Binary Object Representation (CBOR)[RFC8949] providesfor the interchange of structured data without a requirement for apre-agreed schema.[RFC8949] defines a basic set of data types, as well as a taggingmechanism that enables extending the set of data types supported viaan IANA registry.¶
This document defines CBOR tags for object identifiers(OIDs)[X.660], which many IETF protocols carry.The ASN.1 Basic Encoding Rules(BER)[X.690] specify binary encodings of both (absolute) object identifiersand relative object identifiers.The contents of these encodings (the "value" part of BER'stype-length-value structure) can be carried in a CBOR byte string.This document defines two CBOR tags that cover the two kinds ofASN.1 object identifiers encoded in this way and a third one to enable acommon optimization.The tags can also be applied to arrays and maps to efficiently tag allelements of an array or all keys of a map.This document is the reference document for the IANA registration ofthe tags so defined.¶
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; in particular,the term "byte" is used in its now-customary sense as a synonym for"octet".The verb "to tag (something)" is used to express the construction of aCBOR tag, with the object (something) as the tag content and a tagnumber indicated elsewhere in the sentence (for instance, 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 additional restriction detailed inSection 2.1 (noleading zeros).¶
The International Object Identifier tree[X.660] isa hierarchically managed space ofidentifiers, each of which is uniquely represented as a sequence ofunsigned integer values[X.680].(These integer values are called "primary integer values" in[X.660] because they can be accompanied by (not necessarily unambiguous)secondary identifiers. We ignore the latter and simply use the term"integer values" here, occasionally calling out their unsignedness.We also use the term "arc" when the focus is on the edge of the treelabeled by such an integer value, as well as in the sense of a "longarc", i.e., a (sub)sequence of such integer values.)¶
While these sequences can easily be represented in CBOR arrays ofunsigned integers, a more compact representation can often be achievedby adopting the widely used representation of object identifiersdefined in BER; this representation may also be more amenable toprocessing by other software that makes use of object identifiers.¶
BER represents the sequence of unsigned integers by concatenatingself-delimiting representations[RFC6256] of each of the integer values in sequence.¶
ASN.1 distinguishes absolute object identifiers (ASN.1 typeOBJECT IDENTIFIER),which begin at a root arc ([X.660], Clause 3.5.21), from relative objectidentifiers (ASN.1 typeRELATIVE-OID), which beginrelative to some object identifier known from context ([X.680],Clause 3.8.63).As a special optimization,BER combines the first two integers in an absolute object identifierinto one numeric identifier by making use of the property of thehierarchy that the first arc has only three integer values (0, 1, and 2)and the second arcs under 0 and 1 are limited to the integer values between0 and 39. (The root arcjoint-iso-itu-t(2) hasno such limitations on its second arc.)If X and Y are the first two integer values,the single integer value actually encoded is computed as:¶
X * 40 + Y¶
The inverse transformation (again making use of the known ranges of Xand Y) is applied when decoding the object identifier.¶
Since the semantics of absolute and relative object identifiersdiffer and since it is very common for companies to use self-assigned numbersunder the arc1.3.6.1.4.1 (IANA Private Enterprise Number OID[IANA.enterprise-numbers]) that adds 5 fixed bytes to an encoded OID value,this specification defines three tags, collectively called the"OID tags" here:¶
1.3.6.1.4.1 (IANA Private Enterprise Number OID[IANA.enterprise-numbers]). Hence, thesemantics of the result are that of an absolute object identifier.¶To form a valid tag, a byte string tagged with 111, 110, or 112MUST be syntactically valid contents (the value part) for a BERrepresentation of an object identifier (seeTable 1):¶
| Tag number | Section of[X.690] |
|---|---|
| 111 | 8.19 |
| 110 | 8.20 |
| 112 | 8.20 |
This is a concatenation of zero ormore SDNV values, where each SDNV value is a sequence of one or more bytes thatall have their most significant bit set, except for the last byte,where it is unset.Also, the first byte of each SDNV cannot be aleading zero in SDNV's base-128 arithmetic, so it cannot take thevalue 0x80 (bullet (c) in Section 8.1.2.4.2 of[X.690]).¶
In other words:¶
If either of these invalid conditions are encountered, the tag isinvalid.¶
[X.680] restricts RELATIVE-OID values to having at leastone arc, i.e., their encoding would have at least one SDNV.This specification permitsempty relative object identifiers; they maystill be excluded by application semantics.¶
To facilitate the search for specific object ID values, it isRECOMMENDEDthat definite length encoding (seeSection 3.2.3 of [RFC8949]) be usedfor the byte strings that are used as tag content for these tags.¶
The valid set of byte strings can also be expressed using regularexpressions on bytes, using no specific notation but resembling Perl Compatible Regular Expressions[PCRE]. Unlike typical regular expressions that operate oncharacter sequences, the following regular expressions take bytes astheir domain, so they can be applied 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 with tagged content that does not conform to the applicableregular expression is invalid.¶
For an absolute OID with a prefix of1.3.6.1.4.1, representationswith both the 111 and 112 tags are applicable, where therepresentation with 112 will be five bytes shorter (by leaving outthe prefix h'2b06010401' from the enclosed byte string).This specification makes that shorter representation the preferredserialization (see Sections3.4 and4.1 of[RFC8949]).Note that this also implies that the Core Deterministic EncodingRequirements (Section 4.2.1 of [RFC8949]) require the use of 112tags instead of 111 tags wherever that is possible.¶
Staying close to the way object identifiers are encoded in ASN.1BER makes back-and-forth translation easy; otherwise, we would choose amore efficient encoding. Objectidentifiers in IETF protocolsare serialized in dotted decimal form or BER form, sothere is an advantage in not inventing a third form. Also,expectations of the cost of encoding object identifiers arebased on BER; using a different encoding might not be aligned withthese expectations. If additional information about an OID is desired,lookup services such astheOID Resolution Service (ORS) [X.672]and theOID Repository [OID-INFO] are available.¶
This section gives simple examples of an absolute and a relativeobject identifier, represented via tag numbers 111 and 110,respectively.¶
{ joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistalgorithm(4) hashalgs(2) sha256(1) }¶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
D8 6F # tag(111) 49 # 0b010_01001: mt 2, 9 bytes 60 86 48 01 65 03 04 02 01 # X.690 Clause 8.19
Given some OID (e.g.,lowpanMib, assumed to be1.3.6.1.2.1.226[RFC7388]),to which the following is added:¶
{ lowpanObjects(1) lowpanStats(1) lowpanOutTransmits(29) }¶.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
D8 6E # tag(110) 43 # 0b010_00011: mt 2 (bstr), 3 bytes 01 01 1D # X.690 Clause 8.20
This relative OID saves seven bytes compared to the full OID encoding.¶
The tag content of OID tags can be byte strings (as discussed above) but also CBOR arrays and maps.The idea in the latter case is thatthe tag construct is factored out from each individual item in the container;the tag is placed on the array or map instead.¶
When the tag content of an OID tag is an array, this meansthat the respective tag is imputed to all elements of the array that arebyte strings, arrays, or maps. (There is no effect on other elements,including text strings or tags.)For example, when the tag content of a 111 tag is an array,every array element that is a byte stringis an OID, and every element that is an array or map is, in turn,treated as discussed here.¶
When the tag content of an OID tag is a map, this means that a tagwith the same tag number is imputed to all keys in the map that are bytestrings, arrays, or maps; again, there is no effect on keys of other major types.Note that there is also no effect on the values in the map.¶
As a result of these rules, tag factoring in nested arrays and maps is supported.For example,a 3-dimensional array of OIDs can be composed by usinga single 111 tag containing an array of arrays of arraysof byte strings. All such byte strings are then considered OIDs.¶
Where tag factoring with tag number 111 is used, some OIDs enclosed in thetag may be encoded in a shorter way by using tag number 112 instead ofencoding an unadorned byte string.This remains the preferred serialization (see alsoSection 2.2).However, this specification does not make the presence or absence oftag factoring a preferred serialization; application protocols candefine where tag factoring is to be used or not (and will need to doso if they have deterministic encoding requirements).¶
Consider the X.500 distinguished name:¶
| Attribute Types | Attribute Values |
|---|---|
| c (2.5.4.6) | US |
| l (2.5.4.7) s (2.5.4.8) postalCode (2.5.4.17) | Los Angeles CA 90013 |
| street (2.5.4.9) | 532 S Olive St |
| businessCategory (2.5.4.15) buildingName (0.9.2342.19200300.100.1.48) | Public Park Pershing Square |
Table 2 has four "relative distinguished names" (RDNs). Thecountry (first) and street (third) RDNs are single valued.The second and fourth RDNs are multivalued.¶
The equivalent representations in CBOR diagnostic notation (Section 8 of [RFC8949]) and CBOR are:¶
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" }])d8 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"
(This example encoding assumes that all attribute values are UTF-8 strings or can be represented as UTF-8 strings with no loss of information.)¶
Concise Data Definition Language (CDDL) specifications[RFC8610] maywant to specify the use of SDNVs or SDNVsequences (as defined for the tag content for tag 110). This documentintroduces two new control operators that can be applied to a targetvalue that is a byte string:¶
.sdnv, with a control type that contains unsigned integers. Thebyte string is specified to be encoded as an SDNV (BERencoding)[RFC6256] for the matching values of the control type.¶.sdnvseq, with a control type that contains arrays of unsignedintegers. The byte string is specified to be encoded as a sequenceof SDNVs (BER encoding)[RFC6256] that decodes to an array ofunsigned integers matching the control type.¶.oid, like.sdnvseq, except that the X*40+Y translation forabsolute OIDs is included (seeFigure 8).¶Figure 7 shows an example for the use of.sdnvseq for a partof a structure using OIDs that could be used inFigure 6;Figure 8 shows the same with the.oid operator.¶
country-rdn = {country-oid => country-value}country-oid = bytes .sdnvseq [85, 4, 6]country-value = text .size 2country-rdn = {country-oid => country-value}country-oid = bytes .oid [2, 5, 4, 6]country-value = text .size 2Note that the control type need not be a literal; for example,bytes .oid[2, 5, 4, *uint] matches all OIDs inside OID arc2.5.4,attributeType.¶
For the use with CDDL, thetype names defined inFigure 9 are recommended:¶
oid = #6.111(bstr)roid = #6.110(bstr)pen = #6.112(bstr)
IANA has assigned the CBOR tag numbers inTable 3 in 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, array, or map | object identifier (BER encoding) | RFC 9090 |
| 110 | byte string, array, or map | relative object identifier (BER encoding); SDNV[RFC6256] sequence | RFC 9090 |
| 112 | byte string, array, or map | object identifier (BER encoding), relative to 1.3.6.1.4.1 | RFC 9090 |
IANA has assigned the CDDL control operators inTable 4 in the "CDDL Control Operators" registry[IANA.cddl], with this document as the specificationreference.¶
| Name | Reference |
|---|---|
| .sdnv | RFC 9090 |
| .sdnvseq | RFC 9090 |
| .oid | RFC 9090 |
The security considerations of[RFC8949] apply.¶
The encodings in Clauses 8.19 and 8.20 of[X.690] are quite compact and unambiguousbutMUST be followed precisely to avoid security pitfalls.In particular, the requirements set out inSection 2.1 of this document need to befollowed; otherwise, an attacker may be able to subvert a checkingprocess by submitting alternative representations that are later takenas the original (or even something else entirely) by another decoderthat is intended to be protected by the checking process.¶
OIDs and relative OIDs can always be treated as opaque byte strings.Actually understanding the structure that was used for generating themis not necessary, and, except for checking the structure requirements,it is stronglyNOT RECOMMENDED to perform anyprocessing of this kind (e.g., converting into dotted notation andback) unless absolutely necessary.If the OIDs are translated into other representations, the usualsecurity considerations for non-trivial representation conversionsapply; the integer values are unlimited in range.¶
An attacker might trick an application into using a byte string insidea tag-factored data item, where the byte string is not actuallyintended to fall under one of the tags defined here. This may causethe application to emit data with semantics different from what wasintended. Applications therefore need to be restrictive with respectto what data items they apply tag factoring to.¶
Sean Leonard started the work on this document in 2014 with anelaborate proposal.Jim Schaad provided a significant review of this document.Rob Wilton's IESG review prompted us to provide preferredserialization considerations.¶