idnits 2.17.1 draft-ietf-cbor-tags-oid-07.txt: -(3): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(611): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 6 instances of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 6 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (19 May 2021) is 1072 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '85' on line 462 -- Looks like a reference, but probably isn't: '4' on line 468 -- Looks like a reference, but probably isn't: '6' on line 468 -- Looks like a reference, but probably isn't: '2' on line 468 -- Looks like a reference, but probably isn't: '5' on line 468 ** Downref: Normative reference to an Informational RFC: RFC 6256 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Bormann 3 Internet-Draft Universität Bremen TZI 4 Intended status: Standards Track 19 May 2021 5 Expires: 20 November 2021 7 Concise Binary Object Representation (CBOR) Tags for Object Identifiers 8 draft-ietf-cbor-tags-oid-07 10 Abstract 12 The Concise Binary Object Representation (CBOR, RFC 8949) is a data 13 format whose design goals include the possibility of extremely small 14 code size, fairly small message size, and extensibility without the 15 need for version negotiation. 17 The present document defines CBOR tags for object identifiers (OIDs). 18 It is intended as the reference document for the IANA registration of 19 the CBOR tags so defined. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on 20 November 2021. 38 Copyright Notice 40 Copyright (c) 2021 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 45 license-info) in effect on the date of publication of this document. 46 Please review these documents carefully, as they describe your rights 47 and restrictions with respect to this document. Code Components 48 extracted from this document must include Simplified BSD License text 49 as described in Section 4.e of the Trust Legal Provisions and are 50 provided without warranty as described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Object Identifiers . . . . . . . . . . . . . . . . . . . . . 3 57 2.1. Requirements on the byte string being tagged . . . . . . 5 58 2.2. Preferred Serialization Considerations . . . . . . . . . 6 59 2.3. Discussion . . . . . . . . . . . . . . . . . . . . . . . 6 60 3. Basic Examples . . . . . . . . . . . . . . . . . . . . . . . 6 61 3.1. Encoding of the SHA-256 OID . . . . . . . . . . . . . . . 6 62 3.2. Encoding of a MIB Relative OID . . . . . . . . . . . . . 7 63 4. Tag Factoring with Arrays and Maps . . . . . . . . . . . . . 8 64 4.1. Preferred Serialization Considerations . . . . . . . . . 8 65 4.2. Tag Factoring Example: X.500 Distinguished Name . . . . . 8 66 5. CDDL Control Operators . . . . . . . . . . . . . . . . . . . 10 67 6. CDDL typenames . . . . . . . . . . . . . . . . . . . . . . . 11 68 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 69 7.1. CBOR Tags . . . . . . . . . . . . . . . . . . . . . . . . 11 70 7.2. CDDL Control Operators . . . . . . . . . . . . . . . . . 12 71 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 72 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 73 9.1. Normative References . . . . . . . . . . . . . . . . . . 13 74 9.2. Informative References . . . . . . . . . . . . . . . . . 14 75 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 15 76 A.1. Changes from -06 to -07 . . . . . . . . . . . . . . . . . 15 77 A.2. Changes from -05 to -06 . . . . . . . . . . . . . . . . . 15 78 A.3. Changes from -04 to -05 . . . . . . . . . . . . . . . . . 15 79 A.4. Changes from -03 to -04 . . . . . . . . . . . . . . . . . 15 80 A.5. Changes from -02 to -03 . . . . . . . . . . . . . . . . . 15 81 A.6. Changes from -01 to -02 . . . . . . . . . . . . . . . . . 15 82 A.7. Changes from -00 to -01 . . . . . . . . . . . . . . . . . 15 83 A.8. Changes from -07 (bormann) to -00 (ietf) . . . . . . . . 16 84 A.9. Changes from -06 to -07 . . . . . . . . . . . . . . . . . 16 85 A.10. Changes from -05 to -06 . . . . . . . . . . . . . . . . . 16 86 A.11. Changes from -04 to -05 . . . . . . . . . . . . . . . . . 16 87 A.12. Changes from -03 to -04 . . . . . . . . . . . . . . . . . 16 88 A.13. Changes from -02 to -03 . . . . . . . . . . . . . . . . . 16 89 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 17 90 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 17 91 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17 93 1. Introduction 95 The Concise Binary Object Representation (CBOR, [RFC8949]) provides 96 for the interchange of structured data without a requirement for a 97 pre-agreed schema. [RFC8949] defines a basic set of data types, as 98 well as a tagging mechanism that enables extending the set of data 99 types supported via an IANA registry. 101 The present document defines CBOR tags for object identifiers (OIDs, 102 [X.660]), which many IETF protocols carry. The ASN.1 Basic Encoding 103 Rules (BER, [X.690]) specify binary encodings of both (absolute) 104 object identifiers and relative object identifiers. The contents of 105 these encodings (the "value" part of BER's type-length-value 106 structure) can be carried in a CBOR byte string. This document 107 defines two CBOR tags that cover the two kinds of ASN.1 object 108 identifiers encoded in this way. The tags can also be applied to 109 arrays and maps to efficiently tag all elements of an array or all 110 keys of a map. It is intended as the reference document for the IANA 111 registration of the tags so defined. 113 1.1. Terminology 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 117 "OPTIONAL" in this document are to be interpreted as described in 118 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 119 capitals, as shown here. 121 The terminology of [RFC8949] applies; in particular the term "byte" 122 is used in its now customary sense as a synonym for "octet". The 123 term "SDNV" (Self-Delimiting Numeric Value) is used as defined in 124 [RFC6256], with the additional restriction detailed in Section 2.1 125 (no leading zeros). 127 2. Object Identifiers 129 The International Object Identifier tree [X.660] is a hierarchically 130 managed space of identifiers, each of which is uniquely represented 131 as a sequence of unsigned integer values [X.680]. (These integer 132 values are called "primary integer values" in X.660 because they can 133 be accompanied by (not necessarily unambiguous) secondary 134 identifiers. We ignore the latter and simply use the term "integer 135 values" here, occasionally calling out their unsignedness. We also 136 use the term "arc" when the focus is on the edge of the tree labeled 137 by such an integer value, as well as in the sense of a "long arc", 138 i.e., a (sub)sequence of such integer values.) 139 While these sequences can easily be represented in CBOR arrays of 140 unsigned integers, a more compact representation can often be 141 achieved by adopting the widely used representation of object 142 identifiers defined in BER; this representation may also be more 143 amenable to processing by other software that makes use of object 144 identifiers. 146 BER represents the sequence of unsigned integers by concatenating 147 self-delimiting [RFC6256] representations of each of the integer 148 values in sequence. 150 ASN.1 distinguishes absolute object identifiers (ASN.1 Type "OBJECT 151 IDENTIFIER"), which begin at a root arc ([X.660] Clause 3.5.21), from 152 relative object identifiers (ASN.1 Type "RELATIVE-OID"), which begin 153 relative to some object identifier known from context ([X.680] Clause 154 3.8.63). As a special optimization, BER combines the first two 155 integers in an absolute object identifier into one numeric identifier 156 by making use of the property of the hierarchy that the first arc has 157 only three integer values (0, 1, and 2), and the second arcs under 0 158 and 1 are limited to the integer values between 0 and 39. (The root 159 arc "joint-iso-itu-t(2)" has no such limitations on its second arc.) 160 If X and Y are the first two integer values, the single integer value 161 actually encoded is computed as: 163 X * 40 + Y 165 The inverse transformation (again making use of the known ranges of X 166 and Y) is applied when decoding the object identifier. 168 Since the semantics of absolute and relative object identifiers 169 differ, and it is very common for companies to use self-assigned 170 numbers under the arc "1.3.6.1.4.1" (IANA Private Enterprise Number 171 OID, [IANA.enterprise-numbers]) that adds 5 fixed bytes to an encoded 172 OID value, this specification defines three tags, collectively called 173 the "OID tags" here: 175 Tag TBD111: tags a byte string as the [X.690] encoding of an absolute 176 object identifier (simply "object identifier" or "OID"). 178 Tag TBD110: tags a byte string as the [X.690] encoding of a relative 179 object identifier (also "relative OID"). Since the encoding of each 180 number is the same as for [RFC6256] Self-Delimiting Numeric Values 181 (SDNVs), this tag can also be used for tagging a byte string that 182 contains a sequence of zero or more SDNVs (or a more application- 183 specific tag can be created for such an application). 185 Tag TBD112: structurally like TBD110, but understood to be relative 186 to "1.3.6.1.4.1" (IANA Private Enterprise Number OID, 187 [IANA.enterprise-numbers]). Hence, the semantics of the result are 188 that of an absolute object identifier. 190 2.1. Requirements on the byte string being tagged 192 To form a valid tag, a byte string tagged by TBD111, TBD110, or 193 TBD112 MUST be syntactically valid contents (the value part) for a 194 BER representation of an object identifier (Sections 8.19, 8.20, and 195 8.20 of [X.690], respectively): A concatenation of zero or more SDNV 196 values, where each SDNV value is a sequence of one or more bytes that 197 all have their most significant bit set, except for the last byte, 198 where it is unset. Also, the first byte of each SDNV cannot be a 199 leading zero in SDNV's base-128 arithmetic, so it cannot take the 200 value 0x80 (bullet (c) in Section 8.1.2.4.2 of [X.690]). 202 In other words: 204 * the byte string's first byte, and any byte that follows a byte 205 that has the most significant bit unset, MUST NOT be 0x80 (this 206 requirement requires expressing the integer values in their 207 shortest form, with no leading zeroes) 209 * the byte string's last byte MUST NOT have the most significant bit 210 set (this requirement excludes an incomplete final integer value) 212 If either of these invalid conditions are encountered, the tag is 213 invalid. 215 [X.680] restricts RELATIVE-OID values to have at least one arc, i.e., 216 their encoding would have at least one SDNV. This specification 217 permits empty relative object identifiers; they may still be excluded 218 by application semantics. 220 To facilitate the search for specific object ID values, it is 221 RECOMMENDED that definite length encoding (see Section 3.2.3 of 222 [RFC8949]) is used for the byte strings used as tag content for these 223 tags. 225 The valid set of byte strings can also be expressed using regular 226 expressions on bytes, using no specific notation but resembling 227 [PCRE]. Unlike typical regular expressions that operate on character 228 sequences, the following regular expressions take bytes as their 229 domain, so they can be applied directly to CBOR byte strings. 231 For byte strings with tag TBD111: 233 "/^(([\x81-\xFF][\x80-\xFF]*)?[\x00-\x7F])+$/" 235 For byte strings with tag TBD110 or TBD112: 237 "/^(([\x81-\xFF][\x80-\xFF]*)?[\x00-\x7F])*$/" 239 A tag with tagged content that does not conform to the applicable 240 regular expression is invalid. 242 2.2. Preferred Serialization Considerations 244 For an absolute OID with a prefix of "1.3.6.1.4.1", representations 245 with both the TBD111 and TBD112 tags are applicable, where the 246 representation with TBD112 will be five bytes shorter (by leaving out 247 the prefix h'2b06010401' from the enclosed byte string). This 248 specification makes that shorter representation the preferred 249 serialization (see Sections 3.4 and 4.1 of [RFC8949]). Note that 250 this also implies that the Core Deterministic Encoding Requirements 251 (Section 4.2.1 of [RFC8949]) require the use of TBD112 tags instead 252 of TBD111 wherever that is possible. 254 2.3. Discussion 256 Staying close to the way object identifiers are encoded in ASN.1 BER 257 makes back-and-forth translation easy; otherwise we would choose a 258 more efficient encoding. Object identifiers in IETF protocols are 259 serialized in dotted decimal form or BER form, so there is an 260 advantage in not inventing a third form. Also, expectations of the 261 cost of encoding object identifiers are based on BER; using a 262 different encoding might not be aligned with these expectations. If 263 additional information about an OID is desired, lookup services such 264 as the OID Resolution Service (ORS) [X.672] and the OID Repository 265 [OID-INFO] are available. 267 3. Basic Examples 269 This section gives simple examples of an absolute and a relative 270 object identifier, represented via tag number TBD111 and TBD110, 271 respectively. 273 RFC editor: These and other examples assume the allocation of 111 for 274 TBD111 and 110 for TBD110 and need to be changed if that isn't the 275 actual allocation. Please remove this paragraph. 277 3.1. Encoding of the SHA-256 OID 279 ASN.1 Value Notation: { joint-iso-itu-t(2) country(16) us(840) 280 organization(1) gov(101) csor(3) nistalgorithm(4) hashalgs(2) 281 sha256(1) } 283 Dotted Decimal Notation: 2.16.840.1.101.3.4.2.1 285 06 # UNIVERSAL TAG 6 286 09 # 9 bytes, primitive 287 60 86 48 01 65 03 04 02 01 # X.690 Clause 8.19 288 # | 840 1 | 3 4 2 1 show component encoding 289 # 2.16 101 291 Figure 1: SHA-256 OID in BER 293 D8 6F # tag(111) 294 49 # 0b010_01001: mt 2, 9 bytes 295 60 86 48 01 65 03 04 02 01 # X.690 Clause 8.19 297 Figure 2: SHA-256 OID in CBOR 299 3.2. Encoding of a MIB Relative OID 301 Given some OID (e.g., "lowpanMib", assumed to be "1.3.6.1.2.1.226" 302 [RFC7388]), to which the following is added: 304 ASN.1 Value Notation: { lowpanObjects(1) lowpanStats(1) 305 lowpanOutTransmits(29) } 307 Dotted Decimal Notation: .1.1.29 309 0D # UNIVERSAL TAG 13 310 03 # 3 bytes, primitive 311 01 01 1D # X.690 Clause 8.20 312 # 1 1 29 show component encoding 314 Figure 3: MIB relative object identifier, in BER 316 D8 6E # tag(110) 317 43 # 0b010_00011: mt 2 (bstr), 3 bytes 318 01 01 1D # X.690 Clause 8.20 320 Figure 4: MIB relative object identifier, in CBOR 322 This relative OID saves seven bytes compared to the full OID 323 encoding. 325 4. Tag Factoring with Arrays and Maps 327 OID tags can tag byte strings (as discussed above), but also CBOR 328 arrays and maps. The idea in the latter case is that the tag is 329 factored out from each individual item in the container; the tag is 330 placed on the array or map instead. 332 When an OID tag is applied to an array, it means that the respective 333 tag is imputed to all elements of the array that are byte strings, 334 arrays, or maps. (There is no effect on other elements, including 335 text strings or tags.) For example, when an array is tagged with 336 TBD111, every array element that is a byte string is an OID, and 337 every element that is an array or map is in turn treated as discussed 338 here. 340 When an OID tag is applied to a map, it means that the respective tag 341 is imputed to all keys in the map that are byte strings, arrays, or 342 maps; again, there is no effect on keys of other major types. Note 343 that there is also no effect on the values in the map. 345 As a result of these rules, tag factoring in nested arrays and maps 346 is supported. For example, a 3-dimensional array of OIDs can be 347 composed by using a single TBD111 tag containing an array of arrays 348 of arrays of byte strings. All such byte strings are then considered 349 OIDs. 351 4.1. Preferred Serialization Considerations 353 Where tag factoring with tag TBD111 is used, some OIDs enclosed in 354 the tag may be encoded in a shorter way by using tag TBD112 instead 355 of encoding an unadorned byte string. This remains the preferred 356 serialization (see also Section 2.2). However, this specification 357 does not make the presence or absence of tag factoring a preferred 358 serialization; application protocols can define where tag factoring 359 is to be used or not (and will need to do so if they have 360 deterministic encoding requirements). 362 4.2. Tag Factoring Example: X.500 Distinguished Name 364 Consider the X.500 distinguished name: 366 +==============================+=============+ 367 | Attribute Types | Attribute | 368 | | Values | 369 +==============================+=============+ 370 | c (2.5.4.6) | US | 371 +------------------------------+-------------+ 372 | l (2.5.4.7) | Los Angeles | 373 | s (2.5.4.8) | CA | 374 | postalCode (2.5.4.17) | 90013 | 375 +------------------------------+-------------+ 376 | street (2.5.4.9) | 532 S Olive | 377 | | St | 378 +------------------------------+-------------+ 379 | businessCategory (2.5.4.15) | Public Park | 380 | buildingName | Pershing | 381 | (0.9.2342.19200300.100.1.48) | Square | 382 +------------------------------+-------------+ 384 Table 1: Example X.500 Distinguished Name 386 Table 1 has four "relative distinguished names" (RDNs). The country 387 (first) and street (third) RDNs are single-valued. The second and 388 fourth RDNs are multi-valued. 390 The equivalent representations in CBOR diagnostic notation (Section 8 391 of [RFC8949]) and CBOR are: 393 111([{ h'550406': "US" }, 394 { h'550407': "Los Angeles", 395 h'550408': "CA", 396 h'550411': "90013" }, 397 { h'550409': "532 S Olive St" }, 398 { h'55040f': "Public Park", 399 h'0992268993f22c640130': "Pershing Square" }]) 401 Figure 5: Distinguished Name, in CBOR Diagnostic Notation 403 d8 6f # tag(111) 404 84 # array(4) 405 a1 # map(1) 406 43 550406 # 2.5.4.6 (4) 407 62 # text(2) 408 5553 # "US" 409 a3 # map(3) 410 43 550407 # 2.5.4.7 (4) 411 6b # text(11) 412 4c6f7320416e67656c6573 # "Los Angeles" 413 43 550408 # 2.5.4.8 (4) 414 62 # text(2) 415 4341 # "CA" 416 43 550411 # 2.5.4.17 (4) 417 65 # text(5) 418 3930303133 # "90013" 419 a1 # map(1) 420 43 550409 # 2.5.4.9 (4) 421 6e # text(14) 422 3533322053204f6c697665205374 # "532 S Olive St" 423 a2 # map(2) 424 43 55040f # 2.5.4.15 (4) 425 6b # text(11) 426 5075626c6963205061726b # "Public Park" 427 4a 0992268993f22c640130 # 0.9.2342.19200300.100.1.48 (11) 428 6f # text(15) 429 5065727368696e6720537175617265 # "Pershing Square" 431 Figure 6: Distinguished Name, in CBOR (109 bytes) 433 (This example encoding assumes that all attribute values are UTF-8 434 strings, or can be represented as UTF-8 strings with no loss of 435 information.) 437 5. CDDL Control Operators 439 Concise Data Definition Language (CDDL [RFC8610]) specifications may 440 want to specify the use of SDNVs or SDNV sequences (as defined for 441 the tag content for TBD110). This document introduces two new 442 control operators that can be applied to a target value that is a 443 byte string: 445 * ".sdnv", with a control type that contains unsigned integers. The 446 byte string is specified to be encoded as an [RFC6256] SDNV (BER 447 encoding) for the matching values of the control type. 449 * ".sdnvseq", with a control type that contains arrays of unsigned 450 integers. The byte string is specified to be encoded as a 451 sequence of [RFC6256] SDNVs (BER encoding) that decodes to an 452 array of unsigned integers matching the control type. 454 * ".oid", like ".sdnvseq", except that the X*40+Y translation for 455 absolute OIDs is included (see Figure 8). 457 Figure 7 shows an example for the use of ".sdnvseq" for a part of a 458 structure using OIDs that could be used in Figure 6; Figure 8 shows 459 the same with the ".oid" operator. 461 country-rdn = {country-oid => country-value} 462 country-oid = bytes .sdnvseq [85, 4, 6] 463 country-value = text .size 2 465 Figure 7: Using .sdnvseq 467 country-rdn = {country-oid => country-value} 468 country-oid = bytes .oid [2, 5, 4, 6] 469 country-value = text .size 2 471 Figure 8: Using .oid 473 Note that the control type need not be a literal; e.g., "bytes .oid 474 [2, 5, 4, *uint]" matches all OIDs inside OID arc 2.5.4, 475 "attributeType". 477 6. CDDL typenames 479 For the use with CDDL, the typenames defined in Figure 9 are 480 recommended: 482 oid = #6.111(bstr) 483 roid = #6.110(bstr) 484 pen = #6.112(bstr) 486 Figure 9: Recommended typenames for CDDL 488 7. IANA Considerations 490 7.1. CBOR Tags 492 IANA is requested to assign in the 1+1 byte space (24..255) of the 493 CBOR tags registry [IANA.cbor-tags] the CBOR tags in Table 2, with 494 the present document as the specification reference. 496 +========+================+============================+============+ 497 | Tag | Data Item | Semantics | Reference | 498 +========+================+============================+============+ 499 | TBD111 | byte string | object identifier (BER | [this | 500 | | or array or | encoding) | document, | 501 | | map | | Section 2] | 502 +--------+----------------+----------------------------+------------+ 503 | TBD110 | byte string | relative object identifier | [this | 504 | | or array or | (BER encoding); | document, | 505 | | map | SDNV [RFC6256] sequence | Section 2] | 506 +--------+----------------+----------------------------+------------+ 507 | TBD112 | byte string | object identifier (BER | [this | 508 | | or array or | encoding), relative to | document, | 509 | | map | 1.3.6.1.4.1 | Section 2] | 510 +--------+----------------+----------------------------+------------+ 512 Table 2: Values for New Tags 514 7.2. CDDL Control Operators 516 IANA is requested to assign in the CDDL Control Operators registry 517 [IANA.cddl] the CDDL Control Operators in Table 3, with the present 518 document as the specification reference. 520 +==========+============================+ 521 | Name | Reference | 522 +==========+============================+ 523 | .sdnv | [this document, Section 5] | 524 +----------+----------------------------+ 525 | .sdnvseq | [this document, Section 5] | 526 +----------+----------------------------+ 527 | .oid | [this document, Section 5] | 528 +----------+----------------------------+ 530 Table 3: New CDDL Operators 532 8. Security Considerations 534 The security considerations of [RFC8949] apply. 536 The encodings in Clauses 8.19 and 8.20 of [X.690] are quite compact 537 and unambiguous, but MUST be followed precisely to avoid security 538 pitfalls. In particular, the requirements set out in Section 2.1 of 539 this document need to be followed; otherwise, an attacker may be able 540 to subvert a checking process by submitting alternative 541 representations that are later taken as the original (or even 542 something else entirely) by another decoder supposed to be protected 543 by the checking process. 545 OIDs and relative OIDs can always be treated as opaque byte strings. 546 Actually understanding the structure that was used for generating 547 them is not necessary, and, except for checking the structure 548 requirements, it is strongly NOT RECOMMENDED to perform any 549 processing of this kind (e.g., converting into dotted notation and 550 back) unless absolutely necessary. If the OIDs are translated into 551 other representations, the usual security considerations for non- 552 trivial representation conversions apply; the integer values are 553 unlimited in range. 555 An attacker might trick an application into using a byte string 556 inside a tag-factored data item, where the byte string is not 557 actually intended to fall under one of the tags defined here. This 558 may cause the application to emit data with semantics different from 559 what was intended. Applications therefore need to be restrictive 560 with respect to what data items they apply tag factoring to. 562 9. References 564 9.1. Normative References 566 [IANA.cbor-tags] 567 IANA, "Concise Binary Object Representation (CBOR) Tags", 568 . 570 [IANA.cddl] 571 IANA, "Concise Data Definition Language (CDDL)", 572 . 574 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 575 Requirement Levels", BCP 14, RFC 2119, 576 DOI 10.17487/RFC2119, March 1997, 577 . 579 [RFC6256] Eddy, W. and E. Davies, "Using Self-Delimiting Numeric 580 Values in Protocols", RFC 6256, DOI 10.17487/RFC6256, May 581 2011, . 583 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 584 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 585 May 2017, . 587 [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data 588 Definition Language (CDDL): A Notational Convention to 589 Express Concise Binary Object Representation (CBOR) and 590 JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, 591 June 2019, . 593 [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object 594 Representation (CBOR)", STD 94, RFC 8949, 595 DOI 10.17487/RFC8949, December 2020, 596 . 598 [X.660] International Telecommunications Union, "Information 599 technology — Procedures for the operation of object 600 identifier registration authorities: General procedures 601 and top arcs of the international object identifier tree", 602 ITU-T Recommendation X.660, July 2011, 603 . 605 [X.680] International Telecommunications Union, "Information 606 technology — Abstract Syntax Notation One (ASN.1): 607 Specification of basic notation", ITU-T Recommendation 608 X.680, August 2015, . 610 [X.690] International Telecommunications Union, "Information 611 technology — ASN.1 encoding rules: Specification of Basic 612 Encoding Rules (BER), Canonical Encoding Rules (CER) and 613 Distinguished Encoding Rules (DER)", ITU-T Recommendation 614 X.690, August 2015, . 616 9.2. Informative References 618 [IANA.enterprise-numbers] 619 IANA, "Enterprise Numbers", 620 . 622 [OID-INFO] Orange SA, "OID Repository", 2016, 623 . 625 [PCRE] Ho, A., "PCRE - Perl Compatible Regular Expressions", 626 2018, . 628 [RFC7388] Schoenwaelder, J., Sehgal, A., Tsou, T., and C. Zhou, 629 "Definition of Managed Objects for IPv6 over Low-Power 630 Wireless Personal Area Networks (6LoWPANs)", RFC 7388, 631 DOI 10.17487/RFC7388, October 2014, 632 . 634 [X.672] International Telecommunications Union, "Information 635 technology — Open systems interconnection — Object 636 identifier resolution system", ITU-T Recommendation X.672, 637 August 2010, . 639 Appendix A. Change Log 641 This section is to be removed before publishing as an RFC. 643 A.1. Changes from -06 to -07 645 * Various editorial changes prompted by IESG feedback; clarify the 646 usage of "SDNV" in this document (no leading zeros). 648 * Add security consideration about tag-factoring. 650 * Make TBD112, where applicable, the preferred serialization (and 651 thus the required deterministic encoding) over TBD111. 653 A.2. Changes from -05 to -06 655 Add references to specific section numbers of [X.690] to better 656 explain validity of enclosed byte string. 658 A.3. Changes from -04 to -05 660 * Update acknowledgements, contributor list, and author list 662 A.4. Changes from -03 to -04 664 Process WGLC and shepherd comments: 666 * Update references (RFC 8949, URIs for ITU-T) 668 * Define arc for this document, reference SDN definition 670 * Restructure, small editorial clarifications 672 A.5. Changes from -02 to -03 674 * Add tag TBD112 for PEN-relative OIDs 676 * Add suggested CDDL typenames; reference RFC8610 678 A.6. Changes from -01 to -02 680 Minor editorial changes, remove some remnants, ready for WGLC. 682 A.7. Changes from -00 to -01 684 Clean up OID tag factoring. 686 A.8. Changes from -07 (bormann) to -00 (ietf) 688 Resubmitted as WG draft after adoption. 690 A.9. Changes from -06 to -07 692 Reduce the draft back to its basic mandate: Describe CBOR tags for 693 what is colloquially know as ASN.1 Object IDs. 695 A.10. Changes from -05 to -06 697 Refreshed the draft to the current date ("keep-alive"). 699 A.11. Changes from -04 to -05 701 Discussed UUID usage in CBOR, and incorporated fixes proposed by 702 Olivier Dubuisson, including fixes regarding OID nomenclature. 704 A.12. Changes from -03 to -04 706 Changes occurred based on limited feedback, mainly centered around 707 the abstract and introduction, rather than substantive technical 708 changes. These changes include: 710 * Changed the title so that it is about tags and techniques. 712 * Rewrote the abstract to describe the content more accurately, and 713 to point out that no changes to the wire protocol are being 714 proposed. 716 * Removed "ASN.1" from "object identifiers", as OIDs are independent 717 of ASN.1. 719 * Rewrote the introduction to be more about the present text. 721 * Proposed a concise OID arc. 723 * Provided binary regular expression forms for OID validation. 725 * Updated IANA registration tables. 727 A.13. Changes from -02 to -03 729 Many significant changes occurred in this version. These changes 730 include: 732 * Expanded the draft scope to be a comprehensive CBOR update. 734 * Added OID-related sections: OID Enumerations, OID Maps and Arrays, 735 and Applications and Examples of OIDs. 737 * Added Tag 36 update (binary MIME, better definitions). 739 * Added stub/experimental sections for X.690 Series Tags (tag <>) 740 and Regular Expressions (tag 35). 742 * Added technique for representing sets and multisets. 744 * Added references and fixed typos. 746 Acknowledgments 748 Sean Leonard started the work on this document in 2014 with an 749 elaborate proposal. Jim Schaad provided a significant review of this 750 document. Rob Wilton's IESG review prompted us to provide preferred 751 serialization considerations. 753 Contributors 755 Sean Leonard 756 Penango, Inc. 757 5900 Wilshire Boulevard 758 21st Floor 759 Los Angeles, CA, 90036 760 United States of America 762 Email: dev+ietf@seantek.com 764 Author's Address 766 Carsten Bormann 767 Universität Bremen TZI 768 Postfach 330440 769 D-28359 Bremen 770 Germany 772 Phone: +49-421-218-63921 773 Email: cabo@tzi.org