idnits 2.17.1 draft-ietf-cbor-tags-oid-06.txt: -(3): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(540): 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 (30 March 2021) is 1117 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 409 -- Looks like a reference, but probably isn't: '4' on line 415 -- Looks like a reference, but probably isn't: '6' on line 415 -- Looks like a reference, but probably isn't: '2' on line 415 -- Looks like a reference, but probably isn't: '5' on line 415 ** 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 30 March 2021 5 Expires: 1 October 2021 7 Concise Binary Object Representation (CBOR) Tags for Object Identifiers 8 draft-ietf-cbor-tags-oid-06 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 1 October 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Object Identifiers . . . . . . . . . . . . . . . . . . . . . 3 56 3. Basic Examples . . . . . . . . . . . . . . . . . . . . . . . 5 57 4. Tag Factoring with Arrays and Maps . . . . . . . . . . . . . 7 58 5. CDDL Control Operators . . . . . . . . . . . . . . . . . . . 9 59 6. CDDL typenames . . . . . . . . . . . . . . . . . . . . . . . 10 60 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 61 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 62 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 63 9.1. Normative References . . . . . . . . . . . . . . . . . . 12 64 9.2. Informative References . . . . . . . . . . . . . . . . . 13 65 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 13 66 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 15 67 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 15 68 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16 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 syntactically valid contents (the value part) for a 166 BER representation of an object identifier (Sections 8.19, 8.20, and 167 8.20 of [X.690], respectively): A concatenation of zero or more SDNV 168 values, where each SDNV value is a sequence of one or more bytes that 169 all have their most significant bit set, except for the last byte, 170 where it is unset. Also, the first byte of each SDNV cannot be a 171 leading zero in SDNV's base-128 arithmetic, so it cannot take the 172 value 0x80 (bullet (c) in Section 8.1.2.4.2 of [X.690]). 174 In other words: 176 * the byte string's first byte, and any byte that follows a byte 177 that has the most significant bit unset, MUST NOT be 0x80 (this 178 requirement requires expressing the integer values in their 179 shortest form, with no leading zeroes) 181 * the byte string's last byte MUST NOT have the most significant bit 182 set (this requirement excludes an incomplete final integer value) 184 If either of these invalid conditions are encountered, the tag is 185 invalid. 187 [X.680] restricts RELATIVE-OID values to have at least one arc, i.e., 188 their encoding would have at least one SDNV. This specification 189 permits empty relative object identifiers; they may still be excluded 190 by application semantics. 192 To facilitate the search for specific object ID values, it is 193 RECOMMENDED that definite length encoding (see Section 3.2.3 of 194 [RFC8949]) is used for the byte strings used as tag content for these 195 tags. 197 The valid set of byte strings can also be expressed using regular 198 expressions on bytes, using no specific notation but resembling 199 [PCRE]. Unlike typical regular expressions that operate on character 200 sequences, the following regular expressions take bytes as their 201 domain, so they can be applied directly to CBOR byte strings. 203 For byte strings with tag TBD111: 205 "/^(([\x81-\xFF][\x80-\xFF]*)?[\x00-\x7F])+$/" 207 For byte strings with tag TBD110 or TBD112: 209 "/^(([\x81-\xFF][\x80-\xFF]*)?[\x00-\x7F])*$/" 211 A tag with tagged content that does not conform to the applicable 212 regexp is invalid. 214 2.2. Discussion 216 Staying close to the way object identifiers are encoded in ASN.1 BER 217 makes back-and-forth translation easy; otherwise we would choose a 218 more efficient encoding. Object identifiers in IETF protocols are 219 serialized in dotted decimal form or BER form, so there is an 220 advantage in not inventing a third form. Also, expectations of the 221 cost of encoding object identifiers are based on BER; using a 222 different encoding might not be aligned with these expectations. If 223 additional information about an OID is desired, lookup services such 224 as the OID Resolution Service (ORS) [X.672] and the OID Repository 225 [OID-INFO] are available. 227 3. Basic Examples 229 This section gives simple examples of an absolute and a relative 230 object identifier, represented via tag number TBD111 and TBD110, 231 respectively. 233 RFC editor: These and other examples assume the allocation of 111 for 234 TBD111 and 110 for TBD110 and need to be changed if that isn't the 235 actual allocation. Please remove this paragraph. 237 3.1. Encoding of the SHA-256 OID 239 ASN.1 Value Notation: { joint-iso-itu-t(2) country(16) us(840) 240 organization(1) gov(101) csor(3) nistalgorithm(4) hashalgs(2) 241 sha256(1) } 243 Dotted Decimal Notation: 2.16.840.1.101.3.4.2.1 245 06 # UNIVERSAL TAG 6 246 09 # 9 bytes, primitive 247 60 86 48 01 65 03 04 02 01 # X.690 Clause 8.19 248 # | 840 1 | 3 4 2 1 show component encoding 249 # 2.16 101 251 Figure 1: SHA-256 OID in BER 253 D8 6F # tag(111) 254 49 # 0b010_01001: mt 2, 9 bytes 255 60 86 48 01 65 03 04 02 01 # X.690 Clause 8.19 257 Figure 2: SHA-256 OID in CBOR 259 3.2. Encoding of a MIB Relative OID 261 Given some OID (e.g., "lowpanMib", assumed to be "1.3.6.1.2.1.226" 262 [RFC7388]), to which the following is added: 264 ASN.1 Value Notation: { lowpanObjects(1) lowpanStats(1) 265 lowpanOutTransmits(29) } 267 Dotted Decimal Notation: .1.1.29 269 0D # UNIVERSAL TAG 13 270 03 # 3 bytes, primitive 271 01 01 1D # X.690 Clause 8.20 272 # 1 1 29 show component encoding 274 Figure 3: MIB relative object identifier, in BER 276 D8 6E # tag(110) 277 43 # 0b010_01001: mt 2 (bstr), 3 bytes 278 01 01 1D # X.690 Clause 8.20 280 Figure 4: MIB relative object identifier, in CBOR 282 This relative OID saves seven bytes compared to the full OID 283 encoding. 285 4. Tag Factoring with Arrays and Maps 287 OID tags can tag byte strings (as discussed above), but also CBOR 288 arrays and maps. The idea in the latter case is that the tag is 289 factored out from each individual item in the container; the tag is 290 placed on the array or map instead. 292 When an OID tag is applied to an array, it means that the respective 293 tag is imputed to all elements of the array that are byte strings, 294 arrays, or maps. (There is no effect on other elements, including 295 text strings or tags.) For example, when an array is tagged with 296 TBD111, every array element that is a byte string is an OID, and 297 every element that is an array or map is in turn treated as discussed 298 here. 300 When an OID tag is applied to a map, it means that the respective tag 301 is imputed to all keys in the map that are byte strings, arrays, or 302 maps; again, there is no effect on keys of other major types. Note 303 that there is also no effect on the values in the map. 305 As a result of these rules, tag factoring in nested arrays and maps 306 is supported. For example, a 3-dimensional array of OIDs can be 307 composed by using a single TBD111 tag containing an array of arrays 308 of arrays of byte strings. All such byte strings are then considered 309 OIDs. 311 4.1. Tag Factoring Example: X.500 Distinguished Name 313 Consider the X.500 distinguished name: 315 +==============================+=============+ 316 | Attribute Types | Attribute | 317 | | Values | 318 +==============================+=============+ 319 | c (2.5.4.6) | US | 320 +------------------------------+-------------+ 321 | l (2.5.4.7) | Los Angeles | 322 | s (2.5.4.8) | CA | 323 | postalCode (2.5.4.17) | 90013 | 324 +------------------------------+-------------+ 325 | street (2.5.4.9) | 532 S Olive | 326 | | St | 327 +------------------------------+-------------+ 328 | businessCategory (2.5.4.15) | Public Park | 329 | buildingName | Pershing | 330 | (0.9.2342.19200300.100.1.48) | Square | 331 +------------------------------+-------------+ 333 Table 1: Example X.500 Distinguished Name 335 Table 1 has four "relative distinguished names" (RDNs). The country 336 and street RDNs are single-valued. The second and fourth RDNs are 337 multi-valued. 339 The equivalent representations in CBOR diagnostic notation (Section 8 340 of [RFC8949]) and CBOR are: 342 111([{ h'550406': "US" }, 343 { h'550407': "Los Angeles", h'550408': "CA", 344 h'550411': "90013" }, 345 { h'550409': "532 S Olive St" }, 346 { h'55040f': "Public Park", 347 h'0992268993f22c640130': "Pershing Square" }]) 349 Figure 5: Distinguished Name, in CBOR Diagnostic Notation 351 d8 6f # tag(111) 352 84 # array(4) 353 a1 # map(1) 354 43 550406 # 2.5.4.6 (4) 355 62 # text(2) 356 5553 # "US" 357 a3 # map(3) 358 43 550407 # 2.5.4.7 (4) 359 6b # text(11) 360 4c6f7320416e67656c6573 # "Los Angeles" 361 43 550408 # 2.5.4.8 (4) 362 62 # text(2) 363 4341 # "CA" 364 43 550411 # 2.5.4.17 (4) 365 65 # text(5) 366 3930303133 # "90013" 367 a1 # map(1) 368 43 550409 # 2.5.4.9 (4) 369 6e # text(14) 370 3533322053204f6c697665205374 # "532 S Olive St" 371 a2 # map(2) 372 43 55040f # 2.5.4.15 (4) 373 6b # text(11) 374 5075626c6963205061726b # "Public Park" 375 4a 0992268993f22c640130 # 0.9.2342.19200300.100.1.48 (11) 376 6f # text(15) 377 5065727368696e6720537175617265 # "Pershing Square" 379 Figure 6: Distinguished Name, in CBOR (109 bytes) 381 (This example encoding assumes that all attribute values are UTF-8 382 strings, or can be represented as UTF-8 strings with no loss of 383 information.) 385 5. CDDL Control Operators 387 CDDL specifications may want to specify the use of SDNVs or SDNV 388 sequences (as defined for the tag content for TBD110). This document 389 introduces two new control operators that can be applied to a target 390 value that is a byte string: 392 * ".sdnv", with a control type that contains unsigned integers. The 393 byte string is specified to be encoded as an [RFC6256] SDNV (BER 394 encoding) for the matching values of the control type. 396 * ".sdnvseq", with a control type that contains arrays of unsigned 397 integers. The byte string is specified to be encoded as a 398 sequence of [RFC6256] SDNVs (BER encoding) that decodes to an 399 array of unsigned integers matching the control type. 401 * ".oid", like ".sdnvseq", except that the X*40+Y translation for 402 absolute OIDs is included (see Figure 8). 404 Figure 7 shows an example for the use of ".sdnvseq" for a part of a 405 structure using OIDs that could be used in Figure 6; Figure 8 shows 406 the same with the ".oid" operator. 408 country-rdn = {country-oid => country-value} 409 country-oid = bytes .sdnvseq [85, 4, 6] 410 country-value = text .size 2 412 Figure 7: Using .sdnvseq 414 country-rdn = {country-oid => country-value} 415 country-oid = bytes .oid [2, 5, 4, 6] 416 country-value = text .size 2 418 Figure 8: Using .oid 420 Note that the control type need not be a literal; e.g., "bytes .oid 421 [2, 5, 4, *uint]" matches all OIDs inside OID arc 2.5.4, 422 "attributeType". 424 6. CDDL typenames 426 For the use with CDDL [RFC8610], the typenames defined in Figure 9 427 are recommended: 429 oid = #6.111(bstr) 430 roid = #6.110(bstr) 431 pen = #6.112(bstr) 433 Figure 9: Recommended typenames for CDDL 435 7. IANA Considerations 437 7.1. CBOR Tags 439 IANA is requested to assign the CBOR tags in Table 2, with the 440 present document as the specification reference. 442 +========+================+============================+ 443 | Tag | Data Item | Semantics | 444 +========+================+============================+ 445 | TBD111 | byte string or | object identifier (BER | 446 | | array or map | encoding) | 447 +--------+----------------+----------------------------+ 448 | TBD110 | byte string or | relative object identifier | 449 | | array or map | (BER encoding); | 450 | | | SDNV [RFC6256] sequence | 451 +--------+----------------+----------------------------+ 452 | TBD112 | byte string or | object identifier (BER | 453 | | array or map | encoding), relative to | 454 | | | 1.3.6.1.4.1 | 455 +--------+----------------+----------------------------+ 457 Table 2: Values for New Tags 459 7.2. CDDL Control Operators 461 IANA is requested to assign the CDDL Control Operators in Table 3, 462 with the present document as the specification reference. 464 +==========+============================+ 465 | Name | Reference | 466 +==========+============================+ 467 | .sdnv | [this document, Section 5] | 468 +----------+----------------------------+ 469 | .sdnvseq | [this document, Section 5] | 470 +----------+----------------------------+ 471 | .oid | [this document, Section 5] | 472 +----------+----------------------------+ 474 Table 3: New CDDL Operators 476 8. Security Considerations 478 The security considerations of [RFC8949] apply. 480 The encodings in Clauses 8.19 and 8.20 of [X.690] are quite compact 481 and unambiguous, but MUST be followed precisely to avoid security 482 pitfalls. In particular, the requirements set out in Section 2.1 of 483 this document need to be followed; otherwise, an attacker may be able 484 to subvert a checking process by submitting alternative 485 representations that are later taken as the original (or even 486 something else entirely) by another decoder supposed to be protected 487 by the checking process. 489 OIDs and relative OIDs can always be treated as opaque byte strings. 490 Actually understanding the structure that was used for generating 491 them is not necessary, and, except for checking the structure 492 requirements, it is strongly NOT RECOMMENDED to perform any 493 processing of this kind (e.g., converting into dotted notation and 494 back) unless absolutely necessary. If the OIDs are translated into 495 other representations, the usual security considerations for non- 496 trivial representation conversions apply; the integer values are 497 unlimited in range. 499 9. References 501 9.1. Normative References 503 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 504 Requirement Levels", BCP 14, RFC 2119, 505 DOI 10.17487/RFC2119, March 1997, 506 . 508 [RFC6256] Eddy, W. and E. Davies, "Using Self-Delimiting Numeric 509 Values in Protocols", RFC 6256, DOI 10.17487/RFC6256, May 510 2011, . 512 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 513 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 514 May 2017, . 516 [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data 517 Definition Language (CDDL): A Notational Convention to 518 Express Concise Binary Object Representation (CBOR) and 519 JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, 520 June 2019, . 522 [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object 523 Representation (CBOR)", STD 94, RFC 8949, 524 DOI 10.17487/RFC8949, December 2020, 525 . 527 [X.660] International Telecommunications Union, "Information 528 technology — Procedures for the operation of object 529 identifier registration authorities: General procedures 530 and top arcs of the international object identifier tree", 531 ITU-T Recommendation X.660, July 2011, 532 . 534 [X.680] International Telecommunications Union, "Information 535 technology — Abstract Syntax Notation One (ASN.1): 536 Specification of basic notation", ITU-T Recommendation 537 X.680, August 2015, . 539 [X.690] International Telecommunications Union, "Information 540 technology — ASN.1 encoding rules: Specification of Basic 541 Encoding Rules (BER), Canonical Encoding Rules (CER) and 542 Distinguished Encoding Rules (DER)", ITU-T Recommendation 543 X.690, August 2015, . 545 9.2. Informative References 547 [IANA.enterprise-numbers] 548 IANA, "enterprise-numbers", 549 . 551 [OID-INFO] Orange SA, "OID Repository", 2016, 552 . 554 [PCRE] Ho, A., "PCRE - Perl Compatible Regular Expressions", 555 2018, . 557 [RFC7388] Schoenwaelder, J., Sehgal, A., Tsou, T., and C. Zhou, 558 "Definition of Managed Objects for IPv6 over Low-Power 559 Wireless Personal Area Networks (6LoWPANs)", RFC 7388, 560 DOI 10.17487/RFC7388, October 2014, 561 . 563 [X.672] International Telecommunications Union, "Information 564 technology — Open systems interconnection — Object 565 identifier resolution system", ITU-T Recommendation X.672, 566 August 2010, . 568 Appendix A. Change Log 570 This section is to be removed before publishing as an RFC. 572 A.1. Changes from -05 to -06 574 Add references to specific section numbers of [X.690] to better 575 explain validity of enclosed byte string. 577 A.2. Changes from -04 to -05 579 * Update acknowledgements, contributor list, and author list 581 A.3. Changes from -03 to -04 583 Process WGLC and shepherd comments: 585 * Update references (RFC 8949, URIs for ITU-T) 587 * Define arc for this document, reference SDN definition 589 * Restructure, small editorial clarifications 591 A.4. Changes from -02 to -03 593 * Add tag TBD112 for PEN-relative OIDs 595 * Add suggested CDDL typenames; reference RFC8610 597 A.5. Changes from -01 to -02 599 Minor editorial changes, remove some remnants, ready for WGLC. 601 A.6. Changes from -00 to -01 603 Clean up OID tag factoring. 605 A.7. Changes from -07 (bormann) to -00 (ietf) 607 Resubmitted as WG draft after adoption. 609 A.8. Changes from -06 to -07 611 Reduce the draft back to its basic mandate: Describe CBOR tags for 612 what is colloquially know as ASN.1 Object IDs. 614 A.9. Changes from -05 to -06 616 Refreshed the draft to the current date ("keep-alive"). 618 A.10. Changes from -04 to -05 620 Discussed UUID usage in CBOR, and incorporated fixes proposed by 621 Olivier Dubuisson, including fixes regarding OID nomenclature. 623 A.11. Changes from -03 to -04 625 Changes occurred based on limited feedback, mainly centered around 626 the abstract and introduction, rather than substantive technical 627 changes. These changes include: 629 * Changed the title so that it is about tags and techniques. 631 * Rewrote the abstract to describe the content more accurately, and 632 to point out that no changes to the wire protocol are being 633 proposed. 635 * Removed "ASN.1" from "object identifiers", as OIDs are independent 636 of ASN.1. 638 * Rewrote the introduction to be more about the present text. 640 * Proposed a concise OID arc. 642 * Provided binary regular expression forms for OID validation. 644 * Updated IANA registration tables. 646 A.12. Changes from -02 to -03 648 Many significant changes occurred in this version. These changes 649 include: 651 * Expanded the draft scope to be a comprehensive CBOR update. 653 * Added OID-related sections: OID Enumerations, OID Maps and Arrays, 654 and Applications and Examples of OIDs. 656 * Added Tag 36 update (binary MIME, better definitions). 658 * Added stub/experimental sections for X.690 Series Tags (tag <>) 659 and Regular Expressions (tag 35). 661 * Added technique for representing sets and multisets. 663 * Added references and fixed typos. 665 Acknowledgments 667 Sean Leonard started the work on this document in 2014 with an 668 elaborate proposal. Jim Schaad provided a significant review of this 669 document. 671 Contributors 673 Sean Leonard 674 Penango, Inc. 675 5900 Wilshire Boulevard 676 21st Floor 677 Los Angeles, CA, 90036 678 United States of America 680 Email: dev+ietf@seantek.com 681 URI: http://www.penango.com/ 683 Author's Address 685 Carsten Bormann 686 Universität Bremen TZI 687 Postfach 330440 688 D-28359 Bremen 689 Germany 691 Phone: +49-421-218-63921 692 Email: cabo@tzi.org