idnits 2.17.1 draft-ietf-cbor-tags-oid-04.txt: -(3): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(539): 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 (27 January 2021) is 1185 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 408 -- Looks like a reference, but probably isn't: '4' on line 414 -- Looks like a reference, but probably isn't: '6' on line 414 -- Looks like a reference, but probably isn't: '2' on line 414 -- Looks like a reference, but probably isn't: '5' on line 414 ** 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 S. Leonard 5 Expires: 31 July 2021 Penango, Inc. 6 27 January 2021 8 Concise Binary Object Representation (CBOR) Tags for Object Identifiers 9 draft-ietf-cbor-tags-oid-04 11 Abstract 13 The Concise Binary Object Representation (CBOR, RFC 8949) is a data 14 format whose design goals include the possibility of extremely small 15 code size, fairly small message size, and extensibility without the 16 need for version negotiation. 18 The present document defines CBOR tags for object identifiers (OIDs). 19 It is intended as the reference document for the IANA registration of 20 the CBOR tags so defined. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on 31 July 2021. 39 Copyright Notice 41 Copyright (c) 2021 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 46 license-info) in effect on the date of publication of this document. 47 Please review these documents carefully, as they describe your rights 48 and restrictions with respect to this document. Code Components 49 extracted from this document must include Simplified BSD License text 50 as described in Section 4.e of the Trust Legal Provisions and are 51 provided without warranty as described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Object Identifiers . . . . . . . . . . . . . . . . . . . . . 3 57 3. Basic Examples . . . . . . . . . . . . . . . . . . . . . . . 5 58 4. Tag Factoring with Arrays and Maps . . . . . . . . . . . . . 7 59 5. CDDL Control Operators . . . . . . . . . . . . . . . . . . . 9 60 6. CDDL typenames . . . . . . . . . . . . . . . . . . . . . . . 10 61 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 62 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 63 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 64 9.1. Normative References . . . . . . . . . . . . . . . . . . 12 65 9.2. Informative References . . . . . . . . . . . . . . . . . 13 66 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 13 67 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 15 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 70 1. Introduction 72 The Concise Binary Object Representation (CBOR, [RFC8949]) provides 73 for the interchange of structured data without a requirement for a 74 pre-agreed schema. [RFC8949] defines a basic set of data types, as 75 well as a tagging mechanism that enables extending the set of data 76 types supported via an IANA registry. 78 The present document defines CBOR tags for object identifiers (OIDs, 79 [X.660]), which many IETF protocols carry. The ASN.1 Basic Encoding 80 Rules (BER, [X.690]) specify binary encodings of both (absolute) 81 object identifiers and relative object identifiers. The contents of 82 these encodings (the "value" part of BER's type-length-value 83 structure) can be carried in a CBOR byte string. This document 84 defines two CBOR tags that cover the two kinds of ASN.1 object 85 identifiers encoded in this way. The tags can also be applied to 86 arrays and maps to efficiently tag all elements of an array or all 87 keys of a map. It is intended as the reference document for the IANA 88 registration of the tags so defined. 90 1.1. Terminology 92 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 93 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 94 "OPTIONAL" in this document are to be interpreted as described in 95 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 96 capitals, as shown here. 98 The terminology of [RFC8949] applies; in particular the term "byte" 99 is used in its now customary sense as a synonym for "octet". The 100 term "SDNV" is used as defined in [RFC6256]. 102 2. Object Identifiers 104 The International Object Identifier tree [X.660] is a hierarchically 105 managed space of identifiers, each of which is uniquely represented 106 as a sequence of unsigned integer values [X.680]. (These integer 107 values are called "primary integer values" in X.660 because they can 108 be accompanied by (not necessarily unambiguous) secondary 109 identifiers. We ignore the latter and simply use the term "integer 110 values" here, occasionally calling out their unsignedness. We also 111 use the term "arc" when the focus is on the edge of the tree labeled 112 by such an integer value, as well as in the sense of a "long arc", 113 i.e. a (sub)sequence of such integer values.) 115 While these sequences can easily be represented in CBOR arrays of 116 unsigned integers, a more compact representation can often be 117 achieved by adopting the widely used representation of object 118 identifiers defined in BER; this representation may also be more 119 amenable to processing by other software that makes use of object 120 identifiers. 122 BER represents the sequence of unsigned integers by concatenating 123 self-delimiting [RFC6256] representations of each of the integer 124 values in sequence. 126 ASN.1 distinguishes absolute object identifiers (ASN.1 Type "OBJECT 127 IDENTIFIER"), which begin at a root arc ([X.660] Clause 3.5.21), from 128 relative object identifiers (ASN.1 Type "RELATIVE-OID"), which begin 129 relative to some object identifier known from context ([X.680] Clause 130 3.8.63). As a special optimization, BER combines the first two 131 integers in an absolute object identifier into one numeric identifier 132 by making use of the property of the hierarchy that the first arc has 133 only three integer values (0, 1, and 2), and the second arcs under 0 134 and 1 are limited to the integer values between 0 and 39. (The root 135 arc "joint-iso-itu-t(2)" has no such limitations on its second arc.) 136 If X and Y are the first two integer values, the single integer value 137 actually encoded is computed as: 139 X * 40 + Y 141 The inverse transformation (again making use of the known ranges of X 142 and Y) is applied when decoding the object identifier. 144 Since the semantics of absolute and relative object identifiers 145 differ, this specification defines two tags, collectively called the 146 "OID tags" here: 148 Tag TBD111: tags a byte string as the [X.690] encoding of an absolute 149 object identifier (simply "object identifier" or "OID"). 151 Tag TBD110: tags a byte string as the [X.690] encoding of a relative 152 object identifier (also "relative OID"). Since the encoding of each 153 number is the same as for [RFC6256] Self-Delimiting Numeric Values 154 (SDNVs), this tag can also be used for tagging a byte string that 155 contains a sequence of zero or more SDNVs. 157 Tag TBD112: structurally like TBD110, but understood to be relative 158 to "1.3.6.1.4.1" (IANA Private Enterprise Number OID, 159 [IANA.enterprise-numbers]). Hence, the semantics of the result are 160 that of an absolute object identifier. 162 2.1. Requirements on the byte string being tagged 164 To form a valid tag, a byte string tagged by TBD111, TBD110, or 165 TBD112 MUST be a syntactically valid BER representation of an object 166 identifier: A concatenation of zero or more SDNV values, where each 167 SDNV value is a sequence of one or more bytes that all have their 168 most significant bit set, except for the last byte, where it is 169 unset. Also, the first byte of each SDNV cannot be a leading zero in 170 SDNV's base-128 arithmetic, so it cannot take the value 0x80 (bullet 171 (c) in Section 8.1.2.4.2 of [X.690]). 173 In other words: 175 * the byte string's first byte, and any byte that follows a byte 176 that has the most significant bit unset, MUST NOT be 0x80 (this 177 requirement requires expressing the integer values in their 178 shortest form, with no leading zeroes) 180 * the byte string's last byte MUST NOT have the most significant bit 181 set (this requirement excludes an incomplete final integer value) 183 If either of these invalid conditions are encountered, the tag is 184 invalid. 186 [X.680] restricts RELATIVE-OID values to have at least one arc, i.e., 187 their encoding would have at least one SDNV. This specification 188 permits empty relative object identifiers; they may still be excluded 189 by application semantics. 191 To facilitate the search for specific object ID values, it is 192 RECOMMENDED that definite length encoding (see Section 3.2.3 of 193 [RFC8949]) is used for the byte strings used as tag content for these 194 tags. 196 The valid set of byte strings can also be expressed using regular 197 expressions on bytes, using no specific notation but resembling 198 [PCRE]. Unlike typical regular expressions that operate on character 199 sequences, the following regular expressions take bytes as their 200 domain, so they can be applied directly to CBOR byte strings. 202 For byte strings with tag TBD111: 204 "/^(([\x81-\xFF][\x80-\xFF]*)?[\x00-\x7F])+$/" 206 For byte strings with tag TBD110 or TBD112: 208 "/^(([\x81-\xFF][\x80-\xFF]*)?[\x00-\x7F])*$/" 210 A tag with tagged content that does not conform to the applicable 211 regexp is invalid. 213 2.2. Discussion 215 Staying close to the way object identifiers are encoded in ASN.1 BER 216 makes back-and-forth translation easy; otherwise we would choose a 217 more efficient encoding. Object identifiers in IETF protocols are 218 serialized in dotted decimal form or BER form, so there is an 219 advantage in not inventing a third form. Also, expectations of the 220 cost of encoding object identifiers are based on BER; using a 221 different encoding might not be aligned with these expectations. If 222 additional information about an OID is desired, lookup services such 223 as the OID Resolution Service (ORS) [X.672] and the OID Repository 224 [OID-INFO] are available. 226 3. Basic Examples 228 This section gives simple examples of an absolute and a relative 229 object identifier, represented via tag number TBD111 and TBD110, 230 respectively. 232 RFC editor: These and other examples assume the allocation of 111 for 233 TBD111 and 110 for TBD110 and need to be changed if that isn't the 234 actual allocation. Please remove this paragraph. 236 3.1. Encoding of the SHA-256 OID 238 ASN.1 Value Notation: { joint-iso-itu-t(2) country(16) us(840) 239 organization(1) gov(101) csor(3) nistalgorithm(4) hashalgs(2) 240 sha256(1) } 242 Dotted Decimal Notation: 2.16.840.1.101.3.4.2.1 244 06 # UNIVERSAL TAG 6 245 09 # 9 bytes, primitive 246 60 86 48 01 65 03 04 02 01 # X.690 Clause 8.19 247 # | 840 1 | 3 4 2 1 show component encoding 248 # 2.16 101 250 Figure 1: SHA-256 OID in BER 252 D8 6F # tag(111) 253 49 # 0b010_01001: mt 2, 9 bytes 254 60 86 48 01 65 03 04 02 01 # X.690 Clause 8.19 256 Figure 2: SHA-256 OID in CBOR 258 3.2. Encoding of a MIB Relative OID 260 Given some OID (e.g., "lowpanMib", assumed to be "1.3.6.1.2.1.226" 261 [RFC7388]), to which the following is added: 263 ASN.1 Value Notation: { lowpanObjects(1) lowpanStats(1) 264 lowpanOutTransmits(29) } 266 Dotted Decimal Notation: .1.1.29 268 0D # UNIVERSAL TAG 13 269 03 # 3 bytes, primitive 270 01 01 1D # X.690 Clause 8.20 271 # 1 1 29 show component encoding 273 Figure 3: MIB relative object identifier, in BER 275 D8 6E # tag(110) 276 43 # 0b010_01001: mt 2 (bstr), 3 bytes 277 01 01 1D # X.690 Clause 8.20 279 Figure 4: MIB relative object identifier, in CBOR 281 This relative OID saves seven bytes compared to the full OID 282 encoding. 284 4. Tag Factoring with Arrays and Maps 286 OID tags can tag byte strings (as discussed above), but also CBOR 287 arrays and maps. The idea in the latter case is that the tag is 288 factored out from each individual item in the container; the tag is 289 placed on the array or map instead. 291 When an OID tag is applied to an array, it means that the respective 292 tag is imputed to all elements of the array that are byte strings, 293 arrays, or maps. (There is no effect on other elements, including 294 text strings or tags.) For example, when an array is tagged with 295 TBD111, every array element that is a byte string is an OID, and 296 every element that is an array or map is in turn treated as discussed 297 here. 299 When an OID tag is applied to a map, it means that the respective tag 300 is imputed to all keys in the map that are byte strings, arrays, or 301 maps; again, there is no effect on keys of other major types. Note 302 that there is also no effect on the values in the map. 304 As a result of these rules, tag factoring in nested arrays and maps 305 is supported. For example, a 3-dimensional array of OIDs can be 306 composed by using a single TBD111 tag containing an array of arrays 307 of arrays of byte strings. All such byte strings are then considered 308 OIDs. 310 4.1. Tag Factoring Example: X.500 Distinguished Name 312 Consider the X.500 distinguished name: 314 +==============================+=============+ 315 | Attribute Types | Attribute | 316 | | Values | 317 +==============================+=============+ 318 | c (2.5.4.6) | US | 319 +------------------------------+-------------+ 320 | l (2.5.4.7) | Los Angeles | 321 | s (2.5.4.8) | CA | 322 | postalCode (2.5.4.17) | 90013 | 323 +------------------------------+-------------+ 324 | street (2.5.4.9) | 532 S Olive | 325 | | St | 326 +------------------------------+-------------+ 327 | businessCategory (2.5.4.15) | Public Park | 328 | buildingName | Pershing | 329 | (0.9.2342.19200300.100.1.48) | Square | 330 +------------------------------+-------------+ 332 Table 1: Example X.500 Distinguished Name 334 Table 1 has four "relative distinguished names" (RDNs). The country 335 and street RDNs are single-valued. The second and fourth RDNs are 336 multi-valued. 338 The equivalent representations in CBOR diagnostic notation (Section 8 339 of [RFC8949]) and CBOR are: 341 111([{ h'550406': "US" }, 342 { h'550407': "Los Angeles", h'550408': "CA", 343 h'550411': "90013" }, 344 { h'550409': "532 S Olive St" }, 345 { h'55040f': "Public Park", 346 h'0992268993f22c640130': "Pershing Square" }]) 348 Figure 5: Distinguished Name, in CBOR Diagnostic Notation 350 d8 6f # tag(111) 351 84 # array(4) 352 a1 # map(1) 353 43 550406 # 2.5.4.6 (4) 354 62 # text(2) 355 5553 # "US" 356 a3 # map(3) 357 43 550407 # 2.5.4.7 (4) 358 6b # text(11) 359 4c6f7320416e67656c6573 # "Los Angeles" 360 43 550408 # 2.5.4.8 (4) 361 62 # text(2) 362 4341 # "CA" 363 43 550411 # 2.5.4.17 (4) 364 65 # text(5) 365 3930303133 # "90013" 366 a1 # map(1) 367 43 550409 # 2.5.4.9 (4) 368 6e # text(14) 369 3533322053204f6c697665205374 # "532 S Olive St" 370 a2 # map(2) 371 43 55040f # 2.5.4.15 (4) 372 6b # text(11) 373 5075626c6963205061726b # "Public Park" 374 4a 0992268993f22c640130 # 0.9.2342.19200300.100.1.48 (11) 375 6f # text(15) 376 5065727368696e6720537175617265 # "Pershing Square" 378 Figure 6: Distinguished Name, in CBOR (109 bytes) 380 (This example encoding assumes that all attribute values are UTF-8 381 strings, or can be represented as UTF-8 strings with no loss of 382 information.) 384 5. CDDL Control Operators 386 CDDL specifications may want to specify the use of SDNVs or SDNV 387 sequences (as defined for the tag content for TBD110). This document 388 introduces two new control operators that can be applied to a target 389 value that is a byte string: 391 * ".sdnv", with a control type that contains unsigned integers. The 392 byte string is specified to be encoded as an [RFC6256] SDNV (BER 393 encoding) for the matching values of the control type. 395 * ".sdnvseq", with a control type that contains arrays of unsigned 396 integers. The byte string is specified to be encoded as a 397 sequence of [RFC6256] SDNVs (BER encoding) that decodes to an 398 array of unsigned integers matching the control type. 400 * ".oid", like ".sdnvseq", except that the X*40+Y translation for 401 absolute OIDs is included (see Figure 8). 403 Figure 7 shows an example for the use of ".sdnvseq" for a part of a 404 structure using OIDs that could be used in Figure 6; Figure 8 shows 405 the same with the ".oid" operator. 407 country-rdn = {country-oid => country-value} 408 country-oid = bytes .sdnvseq [85, 4, 6] 409 country-value = text .size 2 411 Figure 7: Using .sdnvseq 413 country-rdn = {country-oid => country-value} 414 country-oid = bytes .oid [2, 5, 4, 6] 415 country-value = text .size 2 417 Figure 8: Using .oid 419 Note that the control type need not be a literal; e.g., "bytes .oid 420 [2, 5, 4, *uint]" matches all OIDs inside OID arc 2.5.4, 421 "attributeType". 423 6. CDDL typenames 425 For the use with CDDL [RFC8610], the typenames defined in Figure 9 426 are recommended: 428 oid = #6.111(bstr) 429 roid = #6.110(bstr) 430 pen = #6.112(bstr) 432 Figure 9: Recommended typenames for CDDL 434 7. IANA Considerations 436 7.1. CBOR Tags 438 IANA is requested to assign the CBOR tags in Table 2, with the 439 present document as the specification reference. 441 +========+================+============================+ 442 | Tag | Data Item | Semantics | 443 +========+================+============================+ 444 | TBD111 | byte string or | object identifier (BER | 445 | | array or map | encoding) | 446 +--------+----------------+----------------------------+ 447 | TBD110 | byte string or | relative object identifier | 448 | | array or map | (BER encoding); | 449 | | | SDNV [RFC6256] sequence | 450 +--------+----------------+----------------------------+ 451 | TBD112 | byte string or | object identifier (BER | 452 | | array or map | encoding), relative to | 453 | | | 1.3.6.1.4.1 | 454 +--------+----------------+----------------------------+ 456 Table 2: Values for New Tags 458 7.2. CDDL Control Operators 460 IANA is requested to assign the CDDL Control Operators in Table 3, 461 with the present document as the specification reference. 463 +==========+============================+ 464 | Name | Reference | 465 +==========+============================+ 466 | .sdnv | [this document, Section 5] | 467 +----------+----------------------------+ 468 | .sdnvseq | [this document, Section 5] | 469 +----------+----------------------------+ 470 | .oid | [this document, Section 5] | 471 +----------+----------------------------+ 473 Table 3: New CDDL Operators 475 8. Security Considerations 477 The security considerations of [RFC8949] apply. 479 The encodings in Clauses 8.19 and 8.20 of [X.690] are quite compact 480 and unambiguous, but MUST be followed precisely to avoid security 481 pitfalls. In particular, the requirements set out in Section 2.1 of 482 this document need to be followed; otherwise, an attacker may be able 483 to subvert a checking process by submitting alternative 484 representations that are later taken as the original (or even 485 something else entirely) by another decoder supposed to be protected 486 by the checking process. 488 OIDs and relative OIDs can always be treated as opaque byte strings. 489 Actually understanding the structure that was used for generating 490 them is not necessary, and, except for checking the structure 491 requirements, it is strongly NOT RECOMMENDED to perform any 492 processing of this kind (e.g., converting into dotted notation and 493 back) unless absolutely necessary. If the OIDs are translated into 494 other representations, the usual security considerations for non- 495 trivial representation conversions apply; the integer values are 496 unlimited in range. 498 9. References 500 9.1. Normative References 502 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 503 Requirement Levels", BCP 14, RFC 2119, 504 DOI 10.17487/RFC2119, March 1997, 505 . 507 [RFC6256] Eddy, W. and E. Davies, "Using Self-Delimiting Numeric 508 Values in Protocols", RFC 6256, DOI 10.17487/RFC6256, May 509 2011, . 511 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 512 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 513 May 2017, . 515 [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data 516 Definition Language (CDDL): A Notational Convention to 517 Express Concise Binary Object Representation (CBOR) and 518 JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, 519 June 2019, . 521 [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object 522 Representation (CBOR)", STD 94, RFC 8949, 523 DOI 10.17487/RFC8949, December 2020, 524 . 526 [X.660] International Telecommunications Union, "Information 527 technology — Procedures for the operation of object 528 identifier registration authorities: General procedures 529 and top arcs of the international object identifier tree", 530 ITU-T Recommendation X.660, July 2011, 531 . 533 [X.680] International Telecommunications Union, "Information 534 technology — Abstract Syntax Notation One (ASN.1): 535 Specification of basic notation", ITU-T Recommendation 536 X.680, August 2015, . 538 [X.690] International Telecommunications Union, "Information 539 technology — ASN.1 encoding rules: Specification of Basic 540 Encoding Rules (BER), Canonical Encoding Rules (CER) and 541 Distinguished Encoding Rules (DER)", ITU-T Recommendation 542 X.690, August 2015, . 544 9.2. Informative References 546 [IANA.enterprise-numbers] 547 IANA, "enterprise-numbers", 548 . 550 [OID-INFO] Orange SA, "OID Repository", 2016, 551 . 553 [PCRE] Ho, A., "PCRE - Perl Compatible Regular Expressions", 554 2018, . 556 [RFC7388] Schoenwaelder, J., Sehgal, A., Tsou, T., and C. Zhou, 557 "Definition of Managed Objects for IPv6 over Low-Power 558 Wireless Personal Area Networks (6LoWPANs)", RFC 7388, 559 DOI 10.17487/RFC7388, October 2014, 560 . 562 [X.672] International Telecommunications Union, "Information 563 technology — Open systems interconnection — Object 564 identifier resolution system", ITU-T Recommendation X.672, 565 August 2010, . 567 Appendix A. Change Log 569 This section is to be removed before publishing as an RFC. 571 A.1. Changes from -03 to -04 573 Process WGLC and shepherd comments: 575 * Update references (RFC 8949, URIs for ITU-T) 577 * Define arc for this document, reference SDN definition 579 * Restructure, small editorial clarifications 581 A.2. Changes from -02 to -03 583 * Add tag TBD112 for PEN-relative OIDs 585 * Add suggested CDDL typenames; reference RFC8610 587 A.3. Changes from -01 to -02 589 Minor editorial changes, remove some remnants, ready for WGLC. 591 A.4. Changes from -00 to -01 593 Clean up OID tag factoring. 595 A.5. Changes from -07 (bormann) to -00 (ietf) 597 Resubmitted as WG draft after adoption. 599 A.6. Changes from -06 to -07 601 Reduce the draft back to its basic mandate: Describe CBOR tags for 602 what is colloquially know as ASN.1 Object IDs. 604 A.7. Changes from -05 to -06 606 Refreshed the draft to the current date ("keep-alive"). 608 A.8. Changes from -04 to -05 610 Discussed UUID usage in CBOR, and incorporated fixes proposed by 611 Olivier Dubuisson, including fixes regarding OID nomenclature. 613 A.9. Changes from -03 to -04 615 Changes occurred based on limited feedback, mainly centered around 616 the abstract and introduction, rather than substantive technical 617 changes. These changes include: 619 * Changed the title so that it is about tags and techniques. 621 * Rewrote the abstract to describe the content more accurately, and 622 to point out that no changes to the wire protocol are being 623 proposed. 625 * Removed "ASN.1" from "object identifiers", as OIDs are independent 626 of ASN.1. 628 * Rewrote the introduction to be more about the present text. 630 * Proposed a concise OID arc. 632 * Provided binary regular expression forms for OID validation. 634 * Updated IANA registration tables. 636 A.10. Changes from -02 to -03 638 Many significant changes occurred in this version. These changes 639 include: 641 * Expanded the draft scope to be a comprehensive CBOR update. 643 * Added OID-related sections: OID Enumerations, OID Maps and Arrays, 644 and Applications and Examples of OIDs. 646 * Added Tag 36 update (binary MIME, better definitions). 648 * Added stub/experimental sections for X.690 Series Tags (tag <>) 649 and Regular Expressions (tag 35). 651 * Added technique for representing sets and multisets. 653 * Added references and fixed typos. 655 Acknowledgments 657 Jim Schaad provided a review of this document. 659 Authors' Addresses 661 Carsten Bormann 662 Universität Bremen TZI 663 Postfach 330440 664 D-28359 Bremen 665 Germany 667 Phone: +49-421-218-63921 668 Email: cabo@tzi.org 670 Sean Leonard 671 Penango, Inc. 672 5900 Wilshire Boulevard 673 21st Floor 674 Los Angeles, CA, 90036 675 United States of America 676 Email: dev+ietf@seantek.com 677 URI: http://www.penango.com/