idnits 2.17.1 draft-ietf-cbor-tags-oid-08.txt: -(3): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(619): 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 (21 May 2021) is 1042 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 470 -- Looks like a reference, but probably isn't: '4' on line 476 -- Looks like a reference, but probably isn't: '6' on line 476 -- Looks like a reference, but probably isn't: '2' on line 476 -- Looks like a reference, but probably isn't: '5' on line 476 ** 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 21 May 2021 5 Expires: 22 November 2021 7 Concise Binary Object Representation (CBOR) Tags for Object Identifiers 8 draft-ietf-cbor-tags-oid-08 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 22 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 . . . . . . . . . . . . . . . . . . . . . 4 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 . . . . . . . . . . . . . . . . . . . . . . . 7 61 3.1. Encoding of the SHA-256 OID . . . . . . . . . . . . . . . 7 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 . . . . . 9 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, and a third one to enable a common 109 optimization. The tags can also be applied to arrays and maps to 110 efficiently tag all elements of an array or all keys of a map. It is 111 intended as the reference document for the IANA registration of the 112 tags so defined. 114 1.1. Terminology 116 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 117 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 118 "OPTIONAL" in this document are to be interpreted as described in 119 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 120 capitals, as shown here. 122 The terminology of [RFC8949] applies; in particular the term "byte" 123 is used in its now customary sense as a synonym for "octet". The 124 verb "to tag (something)" is used to express the construction of a 125 CBOR tag with the object (something) as the tag content and a tag 126 number indicated elsewhere in the sentence (for instance in a "with" 127 clause, or by the shorthand "an NNN tag" for "a tag with tag number 128 NNN"). The term "SDNV" (Self-Delimiting Numeric Value) is used as 129 defined in [RFC6256], with the additional restriction detailed in 130 Section 2.1 (no leading zeros). 132 2. Object Identifiers 134 The International Object Identifier tree [X.660] is a hierarchically 135 managed space of identifiers, each of which is uniquely represented 136 as a sequence of unsigned integer values [X.680]. (These integer 137 values are called "primary integer values" in X.660 because they can 138 be accompanied by (not necessarily unambiguous) secondary 139 identifiers. We ignore the latter and simply use the term "integer 140 values" here, occasionally calling out their unsignedness. We also 141 use the term "arc" when the focus is on the edge of the tree labeled 142 by such an integer value, as well as in the sense of a "long arc", 143 i.e., a (sub)sequence of such integer values.) 145 While these sequences can easily be represented in CBOR arrays of 146 unsigned integers, a more compact representation can often be 147 achieved by adopting the widely used representation of object 148 identifiers defined in BER; this representation may also be more 149 amenable to processing by other software that makes use of object 150 identifiers. 152 BER represents the sequence of unsigned integers by concatenating 153 self-delimiting [RFC6256] representations of each of the integer 154 values in sequence. 156 ASN.1 distinguishes absolute object identifiers (ASN.1 Type "OBJECT 157 IDENTIFIER"), which begin at a root arc ([X.660] Clause 3.5.21), from 158 relative object identifiers (ASN.1 Type "RELATIVE-OID"), which begin 159 relative to some object identifier known from context ([X.680] Clause 160 3.8.63). As a special optimization, BER combines the first two 161 integers in an absolute object identifier into one numeric identifier 162 by making use of the property of the hierarchy that the first arc has 163 only three integer values (0, 1, and 2), and the second arcs under 0 164 and 1 are limited to the integer values between 0 and 39. (The root 165 arc "joint-iso-itu-t(2)" has no such limitations on its second arc.) 166 If X and Y are the first two integer values, the single integer value 167 actually encoded is computed as: 169 X * 40 + Y 171 The inverse transformation (again making use of the known ranges of X 172 and Y) is applied when decoding the object identifier. 174 Since the semantics of absolute and relative object identifiers 175 differ, and it is very common for companies to use self-assigned 176 numbers under the arc "1.3.6.1.4.1" (IANA Private Enterprise Number 177 OID, [IANA.enterprise-numbers]) that adds 5 fixed bytes to an encoded 178 OID value, this specification defines three tags, collectively called 179 the "OID tags" here: 181 Tag number TBD111: used to tag a byte string as the [X.690] encoding 182 of an absolute object identifier (simply "object identifier" or 183 "OID"). 185 Tag number TBD110: used to tag a byte string as the [X.690] encoding 186 of a relative object identifier (also "relative OID"). Since the 187 encoding of each number is the same as for [RFC6256] Self-Delimiting 188 Numeric Values (SDNVs), this tag can also be used for tagging a byte 189 string that contains a sequence of zero or more SDNVs (or a more 190 application-specific tag can be created for such an application). 192 Tag TBD112: structurally like TBD110, but understood to be relative 193 to "1.3.6.1.4.1" (IANA Private Enterprise Number OID, 194 [IANA.enterprise-numbers]). Hence, the semantics of the result are 195 that of an absolute object identifier. 197 2.1. Requirements on the byte string being tagged 199 To form a valid tag, a byte string tagged with TBD111, TBD110, or 200 TBD112 MUST be syntactically valid contents (the value part) for a 201 BER representation of an object identifier (Sections 8.19, 8.20, and 202 8.20 of [X.690], respectively): A concatenation of zero or more SDNV 203 values, where each SDNV value is a sequence of one or more bytes that 204 all have their most significant bit set, except for the last byte, 205 where it is unset. Also, the first byte of each SDNV cannot be a 206 leading zero in SDNV's base-128 arithmetic, so it cannot take the 207 value 0x80 (bullet (c) in Section 8.1.2.4.2 of [X.690]). 209 In other words: 211 * the byte string's first byte, and any byte that follows a byte 212 that has the most significant bit unset, MUST NOT be 0x80 (this 213 requirement requires expressing the integer values in their 214 shortest form, with no leading zeroes) 216 * the byte string's last byte MUST NOT have the most significant bit 217 set (this requirement excludes an incomplete final integer value) 219 If either of these invalid conditions are encountered, the tag is 220 invalid. 222 [X.680] restricts RELATIVE-OID values to have at least one arc, i.e., 223 their encoding would have at least one SDNV. This specification 224 permits empty relative object identifiers; they may still be excluded 225 by application semantics. 227 To facilitate the search for specific object ID values, it is 228 RECOMMENDED that definite length encoding (see Section 3.2.3 of 229 [RFC8949]) is used for the byte strings used as tag content for these 230 tags. 232 The valid set of byte strings can also be expressed using regular 233 expressions on bytes, using no specific notation but resembling 234 [PCRE]. Unlike typical regular expressions that operate on character 235 sequences, the following regular expressions take bytes as their 236 domain, so they can be applied directly to CBOR byte strings. 238 For byte strings with tag TBD111: 240 "/^(([\x81-\xFF][\x80-\xFF]*)?[\x00-\x7F])+$/" 242 For byte strings with tag TBD110 or TBD112: 244 "/^(([\x81-\xFF][\x80-\xFF]*)?[\x00-\x7F])*$/" 246 A tag with tagged content that does not conform to the applicable 247 regular expression is invalid. 249 2.2. Preferred Serialization Considerations 251 For an absolute OID with a prefix of "1.3.6.1.4.1", representations 252 with both the TBD111 and TBD112 tags are applicable, where the 253 representation with TBD112 will be five bytes shorter (by leaving out 254 the prefix h'2b06010401' from the enclosed byte string). This 255 specification makes that shorter representation the preferred 256 serialization (see Sections 3.4 and 4.1 of [RFC8949]). Note that 257 this also implies that the Core Deterministic Encoding Requirements 258 (Section 4.2.1 of [RFC8949]) require the use of TBD112 tags instead 259 of TBD111 wherever that is possible. 261 2.3. Discussion 263 Staying close to the way object identifiers are encoded in ASN.1 BER 264 makes back-and-forth translation easy; otherwise we would choose a 265 more efficient encoding. Object identifiers in IETF protocols are 266 serialized in dotted decimal form or BER form, so there is an 267 advantage in not inventing a third form. Also, expectations of the 268 cost of encoding object identifiers are based on BER; using a 269 different encoding might not be aligned with these expectations. If 270 additional information about an OID is desired, lookup services such 271 as the OID Resolution Service (ORS) [X.672] and the OID Repository 272 [OID-INFO] are available. 274 3. Basic Examples 276 This section gives simple examples of an absolute and a relative 277 object identifier, represented via tag number TBD111 and TBD110, 278 respectively. 280 RFC editor: These and other examples assume the allocation of 111 for 281 TBD111 and 110 for TBD110 and need to be changed if that isn't the 282 actual allocation. Please remove this paragraph. 284 3.1. Encoding of the SHA-256 OID 286 ASN.1 Value Notation: { joint-iso-itu-t(2) country(16) us(840) 287 organization(1) gov(101) csor(3) nistalgorithm(4) hashalgs(2) 288 sha256(1) } 290 Dotted Decimal Notation: 2.16.840.1.101.3.4.2.1 292 06 # UNIVERSAL TAG 6 293 09 # 9 bytes, primitive 294 60 86 48 01 65 03 04 02 01 # X.690 Clause 8.19 295 # | 840 1 | 3 4 2 1 show component encoding 296 # 2.16 101 298 Figure 1: SHA-256 OID in BER 300 D8 6F # tag(111) 301 49 # 0b010_01001: mt 2, 9 bytes 302 60 86 48 01 65 03 04 02 01 # X.690 Clause 8.19 304 Figure 2: SHA-256 OID in CBOR 306 3.2. Encoding of a MIB Relative OID 308 Given some OID (e.g., "lowpanMib", assumed to be "1.3.6.1.2.1.226" 309 [RFC7388]), to which the following is added: 311 ASN.1 Value Notation: { lowpanObjects(1) lowpanStats(1) 312 lowpanOutTransmits(29) } 314 Dotted Decimal Notation: .1.1.29 316 0D # UNIVERSAL TAG 13 317 03 # 3 bytes, primitive 318 01 01 1D # X.690 Clause 8.20 319 # 1 1 29 show component encoding 321 Figure 3: MIB relative object identifier, in BER 323 D8 6E # tag(110) 324 43 # 0b010_00011: mt 2 (bstr), 3 bytes 325 01 01 1D # X.690 Clause 8.20 327 Figure 4: MIB relative object identifier, in CBOR 329 This relative OID saves seven bytes compared to the full OID 330 encoding. 332 4. Tag Factoring with Arrays and Maps 334 The tag content of OID tags can be byte strings (as discussed above), 335 but also CBOR arrays and maps. The idea in the latter case is that 336 the tag construct is factored out from each individual item in the 337 container; the tag is placed on the array or map instead. 339 When the tag content of an OID tag is an array, this means that the 340 respective tag is imputed to all elements of the array that are byte 341 strings, arrays, or maps. (There is no effect on other elements, 342 including text strings or tags.) For example, when the tag content 343 of a TBD111 tag is an array, every array element that is a byte 344 string is an OID, and every element that is an array or map is in 345 turn treated as discussed here. 347 When the tag content of an OID tag is a map, this means that a tag 348 with the same tag number is imputed to all keys in the map that are 349 byte strings, arrays, or maps; again, there is no effect on keys of 350 other major types. Note that there is also no effect on the values 351 in the map. 353 As a result of these rules, tag factoring in nested arrays and maps 354 is supported. For example, a 3-dimensional array of OIDs can be 355 composed by using a single TBD111 tag containing an array of arrays 356 of arrays of byte strings. All such byte strings are then considered 357 OIDs. 359 4.1. Preferred Serialization Considerations 361 Where tag factoring with tag number TBD111 is used, some OIDs 362 enclosed in the tag may be encoded in a shorter way by using tag 363 number TBD112 instead of encoding an unadorned byte string. This 364 remains the preferred serialization (see also Section 2.2). However, 365 this specification does not make the presence or absence of tag 366 factoring a preferred serialization; application protocols can define 367 where tag factoring is to be used or not (and will need to do so if 368 they have deterministic encoding requirements). 370 4.2. Tag Factoring Example: X.500 Distinguished Name 372 Consider the X.500 distinguished name: 374 +==============================+=============+ 375 | Attribute Types | Attribute | 376 | | Values | 377 +==============================+=============+ 378 | c (2.5.4.6) | US | 379 +------------------------------+-------------+ 380 | l (2.5.4.7) | Los Angeles | 381 | s (2.5.4.8) | CA | 382 | postalCode (2.5.4.17) | 90013 | 383 +------------------------------+-------------+ 384 | street (2.5.4.9) | 532 S Olive | 385 | | St | 386 +------------------------------+-------------+ 387 | businessCategory (2.5.4.15) | Public Park | 388 | buildingName | Pershing | 389 | (0.9.2342.19200300.100.1.48) | Square | 390 +------------------------------+-------------+ 392 Table 1: Example X.500 Distinguished Name 394 Table 1 has four "relative distinguished names" (RDNs). The country 395 (first) and street (third) RDNs are single-valued. The second and 396 fourth RDNs are multi-valued. 398 The equivalent representations in CBOR diagnostic notation (Section 8 399 of [RFC8949]) and CBOR are: 401 111([{ h'550406': "US" }, 402 { h'550407': "Los Angeles", 403 h'550408': "CA", 404 h'550411': "90013" }, 405 { h'550409': "532 S Olive St" }, 406 { h'55040f': "Public Park", 407 h'0992268993f22c640130': "Pershing Square" }]) 409 Figure 5: Distinguished Name, in CBOR Diagnostic Notation 411 d8 6f # tag(111) 412 84 # array(4) 413 a1 # map(1) 414 43 550406 # 2.5.4.6 (4) 415 62 # text(2) 416 5553 # "US" 417 a3 # map(3) 418 43 550407 # 2.5.4.7 (4) 419 6b # text(11) 420 4c6f7320416e67656c6573 # "Los Angeles" 421 43 550408 # 2.5.4.8 (4) 422 62 # text(2) 423 4341 # "CA" 424 43 550411 # 2.5.4.17 (4) 425 65 # text(5) 426 3930303133 # "90013" 427 a1 # map(1) 428 43 550409 # 2.5.4.9 (4) 429 6e # text(14) 430 3533322053204f6c697665205374 # "532 S Olive St" 431 a2 # map(2) 432 43 55040f # 2.5.4.15 (4) 433 6b # text(11) 434 5075626c6963205061726b # "Public Park" 435 4a 0992268993f22c640130 # 0.9.2342.19200300.100.1.48 (11) 436 6f # text(15) 437 5065727368696e6720537175617265 # "Pershing Square" 439 Figure 6: Distinguished Name, in CBOR (109 bytes) 441 (This example encoding assumes that all attribute values are UTF-8 442 strings, or can be represented as UTF-8 strings with no loss of 443 information.) 445 5. CDDL Control Operators 447 Concise Data Definition Language (CDDL [RFC8610]) specifications may 448 want to specify the use of SDNVs or SDNV sequences (as defined for 449 the tag content for TBD110). This document introduces two new 450 control operators that can be applied to a target value that is a 451 byte string: 453 * ".sdnv", with a control type that contains unsigned integers. The 454 byte string is specified to be encoded as an [RFC6256] SDNV (BER 455 encoding) for the matching values of the control type. 457 * ".sdnvseq", with a control type that contains arrays of unsigned 458 integers. The byte string is specified to be encoded as a 459 sequence of [RFC6256] SDNVs (BER encoding) that decodes to an 460 array of unsigned integers matching the control type. 462 * ".oid", like ".sdnvseq", except that the X*40+Y translation for 463 absolute OIDs is included (see Figure 8). 465 Figure 7 shows an example for the use of ".sdnvseq" for a part of a 466 structure using OIDs that could be used in Figure 6; Figure 8 shows 467 the same with the ".oid" operator. 469 country-rdn = {country-oid => country-value} 470 country-oid = bytes .sdnvseq [85, 4, 6] 471 country-value = text .size 2 473 Figure 7: Using .sdnvseq 475 country-rdn = {country-oid => country-value} 476 country-oid = bytes .oid [2, 5, 4, 6] 477 country-value = text .size 2 479 Figure 8: Using .oid 481 Note that the control type need not be a literal; e.g., "bytes .oid 482 [2, 5, 4, *uint]" matches all OIDs inside OID arc 2.5.4, 483 "attributeType". 485 6. CDDL typenames 487 For the use with CDDL, the typenames defined in Figure 9 are 488 recommended: 490 oid = #6.111(bstr) 491 roid = #6.110(bstr) 492 pen = #6.112(bstr) 494 Figure 9: Recommended typenames for CDDL 496 7. IANA Considerations 498 7.1. CBOR Tags 500 IANA is requested to assign in the 1+1 byte space (24..255) of the 501 CBOR tags registry [IANA.cbor-tags] the CBOR tag numbers in Table 2, 502 with the present document as the specification reference. 504 +========+================+============================+============+ 505 | Tag | Data Item | Semantics | Reference | 506 +========+================+============================+============+ 507 | TBD111 | byte string | object identifier (BER | [this | 508 | | or array or | encoding) | document, | 509 | | map | | Section 2] | 510 +--------+----------------+----------------------------+------------+ 511 | TBD110 | byte string | relative object identifier | [this | 512 | | or array or | (BER encoding); | document, | 513 | | map | SDNV [RFC6256] sequence | Section 2] | 514 +--------+----------------+----------------------------+------------+ 515 | TBD112 | byte string | object identifier (BER | [this | 516 | | or array or | encoding), relative to | document, | 517 | | map | 1.3.6.1.4.1 | Section 2] | 518 +--------+----------------+----------------------------+------------+ 520 Table 2: New Tag Numbers 522 7.2. CDDL Control Operators 524 IANA is requested to assign in the CDDL Control Operators registry 525 [IANA.cddl] the CDDL Control Operators in Table 3, with the present 526 document as the specification reference. 528 +==========+============================+ 529 | Name | Reference | 530 +==========+============================+ 531 | .sdnv | [this document, Section 5] | 532 +----------+----------------------------+ 533 | .sdnvseq | [this document, Section 5] | 534 +----------+----------------------------+ 535 | .oid | [this document, Section 5] | 536 +----------+----------------------------+ 538 Table 3: New CDDL Operators 540 8. Security Considerations 542 The security considerations of [RFC8949] apply. 544 The encodings in Clauses 8.19 and 8.20 of [X.690] are quite compact 545 and unambiguous, but MUST be followed precisely to avoid security 546 pitfalls. In particular, the requirements set out in Section 2.1 of 547 this document need to be followed; otherwise, an attacker may be able 548 to subvert a checking process by submitting alternative 549 representations that are later taken as the original (or even 550 something else entirely) by another decoder supposed to be protected 551 by the checking process. 553 OIDs and relative OIDs can always be treated as opaque byte strings. 554 Actually understanding the structure that was used for generating 555 them is not necessary, and, except for checking the structure 556 requirements, it is strongly NOT RECOMMENDED to perform any 557 processing of this kind (e.g., converting into dotted notation and 558 back) unless absolutely necessary. If the OIDs are translated into 559 other representations, the usual security considerations for non- 560 trivial representation conversions apply; the integer values are 561 unlimited in range. 563 An attacker might trick an application into using a byte string 564 inside a tag-factored data item, where the byte string is not 565 actually intended to fall under one of the tags defined here. This 566 may cause the application to emit data with semantics different from 567 what was intended. Applications therefore need to be restrictive 568 with respect to what data items they apply tag factoring to. 570 9. References 572 9.1. Normative References 574 [IANA.cbor-tags] 575 IANA, "Concise Binary Object Representation (CBOR) Tags", 576 . 578 [IANA.cddl] 579 IANA, "Concise Data Definition Language (CDDL)", 580 . 582 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 583 Requirement Levels", BCP 14, RFC 2119, 584 DOI 10.17487/RFC2119, March 1997, 585 . 587 [RFC6256] Eddy, W. and E. Davies, "Using Self-Delimiting Numeric 588 Values in Protocols", RFC 6256, DOI 10.17487/RFC6256, May 589 2011, . 591 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 592 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 593 May 2017, . 595 [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data 596 Definition Language (CDDL): A Notational Convention to 597 Express Concise Binary Object Representation (CBOR) and 598 JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, 599 June 2019, . 601 [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object 602 Representation (CBOR)", STD 94, RFC 8949, 603 DOI 10.17487/RFC8949, December 2020, 604 . 606 [X.660] International Telecommunications Union, "Information 607 technology — Procedures for the operation of object 608 identifier registration authorities: General procedures 609 and top arcs of the international object identifier tree", 610 ITU-T Recommendation X.660, July 2011, 611 . 613 [X.680] International Telecommunications Union, "Information 614 technology — Abstract Syntax Notation One (ASN.1): 615 Specification of basic notation", ITU-T Recommendation 616 X.680, August 2015, . 618 [X.690] International Telecommunications Union, "Information 619 technology — ASN.1 encoding rules: Specification of Basic 620 Encoding Rules (BER), Canonical Encoding Rules (CER) and 621 Distinguished Encoding Rules (DER)", ITU-T Recommendation 622 X.690, August 2015, . 624 9.2. Informative References 626 [IANA.enterprise-numbers] 627 IANA, "Enterprise Numbers", 628 . 630 [OID-INFO] Orange SA, "OID Repository", 2016, 631 . 633 [PCRE] Ho, A., "PCRE - Perl Compatible Regular Expressions", 634 2018, . 636 [RFC7388] Schoenwaelder, J., Sehgal, A., Tsou, T., and C. Zhou, 637 "Definition of Managed Objects for IPv6 over Low-Power 638 Wireless Personal Area Networks (6LoWPANs)", RFC 7388, 639 DOI 10.17487/RFC7388, October 2014, 640 . 642 [X.672] International Telecommunications Union, "Information 643 technology — Open systems interconnection — Object 644 identifier resolution system", ITU-T Recommendation X.672, 645 August 2010, . 647 Appendix A. Change Log 649 This section is to be removed before publishing as an RFC. 651 A.1. Changes from -06 to -07 653 * Various editorial changes prompted by IESG feedback; clarify the 654 usage of "SDNV" in this document (no leading zeros). 656 * Add security consideration about tag-factoring. 658 * Make TBD112, where applicable, the preferred serialization (and 659 thus the required deterministic encoding) over TBD111. 661 A.2. Changes from -05 to -06 663 Add references to specific section numbers of [X.690] to better 664 explain validity of enclosed byte string. 666 A.3. Changes from -04 to -05 668 * Update acknowledgements, contributor list, and author list 670 A.4. Changes from -03 to -04 672 Process WGLC and shepherd comments: 674 * Update references (RFC 8949, URIs for ITU-T) 676 * Define arc for this document, reference SDN definition 678 * Restructure, small editorial clarifications 680 A.5. Changes from -02 to -03 682 * Add tag TBD112 for PEN-relative OIDs 684 * Add suggested CDDL typenames; reference RFC8610 686 A.6. Changes from -01 to -02 688 Minor editorial changes, remove some remnants, ready for WGLC. 690 A.7. Changes from -00 to -01 692 Clean up OID tag factoring. 694 A.8. Changes from -07 (bormann) to -00 (ietf) 696 Resubmitted as WG draft after adoption. 698 A.9. Changes from -06 to -07 700 Reduce the draft back to its basic mandate: Describe CBOR tags for 701 what is colloquially know as ASN.1 Object IDs. 703 A.10. Changes from -05 to -06 705 Refreshed the draft to the current date ("keep-alive"). 707 A.11. Changes from -04 to -05 709 Discussed UUID usage in CBOR, and incorporated fixes proposed by 710 Olivier Dubuisson, including fixes regarding OID nomenclature. 712 A.12. Changes from -03 to -04 714 Changes occurred based on limited feedback, mainly centered around 715 the abstract and introduction, rather than substantive technical 716 changes. These changes include: 718 * Changed the title so that it is about tags and techniques. 720 * Rewrote the abstract to describe the content more accurately, and 721 to point out that no changes to the wire protocol are being 722 proposed. 724 * Removed "ASN.1" from "object identifiers", as OIDs are independent 725 of ASN.1. 727 * Rewrote the introduction to be more about the present text. 729 * Proposed a concise OID arc. 731 * Provided binary regular expression forms for OID validation. 733 * Updated IANA registration tables. 735 A.13. Changes from -02 to -03 737 Many significant changes occurred in this version. These changes 738 include: 740 * Expanded the draft scope to be a comprehensive CBOR update. 742 * Added OID-related sections: OID Enumerations, OID Maps and Arrays, 743 and Applications and Examples of OIDs. 745 * Added Tag 36 update (binary MIME, better definitions). 747 * Added stub/experimental sections for X.690 Series Tags (tag <>) 748 and Regular Expressions (tag 35). 750 * Added technique for representing sets and multisets. 752 * Added references and fixed typos. 754 Acknowledgments 756 Sean Leonard started the work on this document in 2014 with an 757 elaborate proposal. Jim Schaad provided a significant review of this 758 document. Rob Wilton's IESG review prompted us to provide preferred 759 serialization considerations. 761 Contributors 763 Sean Leonard 764 Penango, Inc. 765 5900 Wilshire Boulevard 766 21st Floor 767 Los Angeles, CA, 90036 768 United States of America 770 Email: dev+ietf@seantek.com 772 Author's Address 774 Carsten Bormann 775 Universität Bremen TZI 776 Postfach 330440 777 D-28359 Bremen 778 Germany 780 Phone: +49-421-218-63921 781 Email: cabo@tzi.org