idnits 2.17.1 draft-ietf-cbor-tags-oid-01.txt: -(3): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(523): 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 September 2020) is 1301 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 399 -- Looks like a reference, but probably isn't: '4' on line 405 -- Looks like a reference, but probably isn't: '6' on line 405 -- Looks like a reference, but probably isn't: '2' on line 405 -- Looks like a reference, but probably isn't: '5' on line 405 == Outdated reference: A later version (-16) exists of draft-ietf-cbor-7049bis-15 -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-cbor-7049bis' ** Downref: Normative reference to an Informational RFC: RFC 6256 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 8 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: 3 April 2021 Penango, Inc. 6 30 September 2020 8 Concise Binary Object Representation (CBOR) Tags for Object Identifiers 9 draft-ietf-cbor-tags-oid-01 11 Abstract 13 The Concise Binary Object Representation (CBOR, draft-ietf-cbor- 14 7049bis) is a data format whose design goals include the possibility 15 of extremely small code size, fairly small message size, and 16 extensibility without the 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 3 April 2021. 39 Copyright Notice 41 Copyright (c) 2020 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. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 6 59 5. Tag Factoring with OID Arrays and Maps . . . . . . . . . . . 6 60 6. Applications and Examples of OIDs . . . . . . . . . . . . . . 7 61 7. CDDL Control Operators . . . . . . . . . . . . . . . . . . . 9 62 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 63 9. Security Considerations . . . . . . . . . . . . . . . . . . . 10 64 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 65 10.1. Normative References . . . . . . . . . . . . . . . . . . 11 66 10.2. Informative References . . . . . . . . . . . . . . . . . 12 67 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 12 68 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 14 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 71 1. Introduction 73 The Concise Binary Object Representation (CBOR, 74 [I-D.ietf-cbor-7049bis]) provides for the interchange of structured 75 data without a requirement for a pre-agreed schema. 76 [I-D.ietf-cbor-7049bis] defines a basic set of data types, as well as 77 a tagging mechanism that enables extending the set of data types 78 supported via an IANA registry. 80 The present document defines CBOR tags for object identifiers (OIDs, 81 [X.660]), which many IETF protocols carry. The ASN.1 Basic Encoding 82 Rules (BER, [X.690]) specify binary encodings of both (absolute) 83 object identifiers and relative object identifiers. The contents of 84 these encodings (the "value" part of BER's type-length-value 85 structure) can be carried in a CBOR byte string. This document 86 defines two CBOR tags that cover the two kinds of ASN.1 object 87 identifiers encoded in this way. The tags can also be applied to 88 arrays and maps to efficiently tag all elements of an array or all 89 keys of a map. It is intended as the reference document for the IANA 90 registration of the tags so defined. 92 1.1. Terminology 94 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 95 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 96 "OPTIONAL" in this document are to be interpreted as described in 97 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 98 capitals, as shown here. 100 The terminology of draft-ietf-cbor-7049bis applies; in particular the 101 term "byte" is used in its now customary sense as a synonym for 102 "octet". 104 2. Object Identifiers 106 The International Object Identifier tree [X.660] is a hierarchically 107 managed space of identifiers, each of which is uniquely represented 108 as a sequence of unsigned integer values [X.680]. (These integer 109 values are called "primary integer values" in X.660 because they can 110 be accompanied by (not necessarily unambiguous) secondary 111 identifiers. We ignore the latter and simply use the term "integer 112 values" here, possibly calling out their unsignedness.) 114 While these sequences can easily be represented in CBOR arrays of 115 unsigned integers, a more compact representation can often be 116 achieved by adopting the widely used representation of object 117 identifiers defined in BER; this representation may also be more 118 amenable to processing by other software making use of object 119 identifiers. 121 BER represents the sequence of unsigned integers by concatenating 122 self-delimiting [RFC6256] representations of each of the integer 123 values in sequence. 125 ASN.1 distinguishes absolute object identifiers (ASN.1 Type "OBJECT 126 IDENTIFIER"), which begin at a root arc ([X.660] Clause 3.5.21), from 127 relative object identifiers (ASN.1 Type "RELATIVE-OID"), which begin 128 relative to some object identifier known from context ([X.680] Clause 129 3.8.63). As a special optimization, BER combines the first two 130 integers in an absolute object identifier into one numeric identifier 131 by making use of the property of the hierarchy that the first arc has 132 only three integer values (0, 1, and 2), and the second arcs under 0 133 and 1 are limited to the integer values between 0 and 39. (The root 134 arc "joint-iso-itu-t(2)" has no such limitations on its second arc.) 135 If X and Y are the first two integers, the single integer actually 136 encoded is computed as: 138 X * 40 + Y 140 The inverse transformation (again making use of the known ranges of X 141 and Y) is applied when decoding the object identifier. 143 Since the semantics of absolute and relative object identifiers 144 differ, this specification defines two tags, collectively called the 145 "OID tags" here: 147 Tag TBD111: tags a byte string as the [X.690] encoding of an absolute 148 object identifier (simply "object identifier" or "OID"). 150 Tag TBD110: tags a byte string as the [X.690] encoding of a relative 151 object identifier (also "relative OID"). Since the encoding of each 152 number is the same as for [RFC6256] Self-Delimiting Numeric Values 153 (SDNVs), this tag can also be used for tagging a byte string that 154 contains a sequence of zero or more SDNVs. 156 2.1. Requirements on the byte string being tagged 158 To form a valid tag, a byte string tagged by TBD111 or TBD110 MUST be 159 a syntactically valid BER representation of an object identifier: A 160 concatenation of zero or more SDNV values, where each SDNV value is a 161 sequence of one or more bytes that all have their most significant 162 bit set, except for the last byte, where it must be unset; the first 163 byte of each SDNV cannot be 0x80 (which would be a leading zero in 164 SDNV's base-128 arithmetic). 166 In other words: 168 * its first byte, and any byte that follows a byte that has the most 169 significant bit unset, MUST NOT be 0x80 (this requirement requires 170 expressing the integer values in their shortest form, with no 171 leading zeroes) 173 * its last byte MUST NOT have the most significant bit set (this 174 requirement excludes an incomplete final integer value) 176 If either of these invalid conditions are encountered, the tag is 177 invalid. 179 [X.680] restricts RELATIVE-OID values to have at least one arc, i.e., 180 their encoding would have at least one SDNV. This specification 181 permits empty relative object identifiers; they may still be excluded 182 by application semantics. 184 To facilitate the search for specific object ID values, it is 185 RECOMMENDED that definite length encoding (see Section 3.2.3 of 186 [I-D.ietf-cbor-7049bis]) is used for the byte strings used as tag 187 content for these tags. 189 The valid set of byte strings can also be expressed using regular 190 expressions on bytes, using no specific notation but resembling 191 [PCRE]. Unlike typical regular expressions that operate on character 192 sequences, the following regular expressions take bytes as their 193 domain, so they can be applied directly to CBOR byte strings. 195 For byte strings with tag TBD111: 197 "/^(([\x81-\xFF][\x80-\xFF]*)?[\x00-\x7F])+$/" 199 For byte strings with tag TBD110: 201 "/^(([\x81-\xFF][\x80-\xFF]*)?[\x00-\x7F])*$/" 203 A tag with tagged content that does not conform to the applicable 204 regexp is invalid. 206 3. Examples 208 3.1. Encoding of the SHA-256 OID 210 ASN.1 Value Notation: { joint-iso-itu-t(2) country(16) us(840) 211 organization(1) gov(101) csor(3) nistalgorithm(4) hashalgs(2) 212 sha256(1) } 214 Dotted Decimal Notation: 2.16.840.1.101.3.4.2.1 216 06 # UNIVERSAL TAG 6 217 09 # 9 bytes, primitive 218 60 86 48 01 65 03 04 02 01 # X.690 Clause 8.19 219 # | 840 1 | 3 4 2 1 show component encoding 220 # 2.16 101 222 Figure 1: SHA-256 OID in BER 224 D8 6F # tag(111) 225 49 # 0b010_01001: mt 2, 9 bytes 226 60 86 48 01 65 03 04 02 01 # X.690 Clause 8.19 228 Figure 2: SHA-256 OID in CBOR 230 3.2. Encoding of a MIB Relative OID 232 Given some OID (e.g., "lowpanMib", assumed to be "1.3.6.1.2.1.226" 233 [RFC7388]), to which the following is added: 235 ASN.1 Value Notation: { lowpanObjects(1) lowpanStats(1) 236 lowpanOutTransmits(29) } 238 Dotted Decimal Notation: .1.1.29 240 0D # UNIVERSAL TAG 13 241 03 # 3 bytes, primitive 242 01 01 1D # X.690 Clause 8.20 243 # 1 1 29 show component encoding 245 Figure 3: MIB relative object identifier, in BER 247 D8 6E # tag(110) 248 43 # 0b010_01001: mt 2 (bstr), 3 bytes 249 01 01 1D # X.690 Clause 8.20 251 Figure 4: MIB relative object identifier, in CBOR 253 This relative OID saves seven bytes compared to the full OID 254 encoding. 256 4. Discussion 258 Staying close to the way object identifiers are encoded in ASN.1 BER 259 makes back-and-forth translation easy; otherwise we would choose a 260 more efficient encoding. Object identifiers in IETF protocols are 261 serialized in dotted decimal form or BER form, so there is an 262 advantage in not inventing a third form. Also, expectations of the 263 cost of encoding object identifiers are based on BER; using a 264 different encoding might not be aligned with these expectations. If 265 additional information about an OID is desired, lookup services such 266 as the OID Resolution Service (ORS) [X.672] and the OID Repository 267 [OID-INFO] are available. 269 5. Tag Factoring with OID Arrays and Maps 271 OID tags can tag byte strings (as discussed above), but also CBOR 272 arrays and maps. The idea in the latter case is that the tag is 273 factored out from each individual item in the container; the tag is 274 placed on the array or map instead. 276 When an OID tag is applied to an array, it means that the respective 277 tag is imputed to all elements of the array that are byte strings, 278 arrays, or maps. (There is no effect on other elements, including 279 text strings or tags.) For example, when an array is tagged with 280 TBD111, every array element that is a byte string is an OID, and 281 every element that is an array or map is in turn treated as discussed 282 here. 284 When an OID tag is applied to a map, it means that the respective tag 285 is imputed to all keys in the map that are byte strings, arrays, or 286 maps; again, there is no effect on keys of other major types. Note 287 that there is also no effect on the values in the map. 289 As a result of these rules, tag factoring in nested arrays and maps 290 is supported. For example, a 3-dimensional array of OIDs can be 291 composed by using a single TBD111 tag containing an array of arrays 292 of arrays of byte strings. All such byte strings are then considered 293 OIDs. 294 // Now what may be needed is a tag that can stop the recursive 295 // application. I'm not sure that level complexity is really useful, 296 // instead, simply don't tag-factor arrays with elements or maps with 297 // keys where you are not sure you really want recursive application. 299 6. Applications and Examples of OIDs 301 6.1. X.500 Distinguished Name 303 Consider the X.500 distinguished name: 305 +==============================+=============+ 306 | Attribute Types | Attribute | 307 | | Values | 308 +==============================+=============+ 309 | c (2.5.4.6) | US | 310 +------------------------------+-------------+ 311 | l (2.5.4.7) | Los Angeles | 312 | s (2.5.4.8) | CA | 313 | postalCode (2.5.4.17) | 90013 | 314 +------------------------------+-------------+ 315 | street (2.5.4.9) | 532 S Olive | 316 | | St | 317 +------------------------------+-------------+ 318 | businessCategory (2.5.4.15) | Public Park | 319 | buildingName | Pershing | 320 | (0.9.2342.19200300.100.1.48) | Square | 321 +------------------------------+-------------+ 323 Table 1: Example X.500 Distinguished Name 325 Table 1 has four "relative distinguished names" (RDNs). The country 326 and street RDNs are single-valued. The second and fourth RDNs are 327 multi-valued. 329 The equivalent representations in CBOR diagnostic notation and CBOR 330 are: 332 111([{ h'550406': "US" }, 333 { h'550407': "Los Angeles", h'550408': "CA", 334 h'550411': "90013" }, 335 { h'550409': "532 S Olive St" }, 336 { h'55040f': "Public Park", 337 h'0992268993f22c640130': "Pershing Square" }]) 339 Figure 5: Distinguished Name, in CBOR Diagnostic Notation 341 d8 6f # tag(111) 342 84 # array(4) 343 a1 # map(1) 344 43 550406 # 2.5.4.6 (4) 345 62 # text(2) 346 5553 # "US" 347 a3 # map(3) 348 43 550407 # 2.5.4.7 (4) 349 6b # text(11) 350 4c6f7320416e67656c6573 # "Los Angeles" 351 43 550408 # 2.5.4.8 (4) 352 62 # text(2) 353 4341 # "CA" 354 43 550411 # 2.5.4.17 (4) 355 65 # text(5) 356 3930303133 # "90013" 357 a1 # map(1) 358 43 550409 # 2.5.4.9 (4) 359 6e # text(14) 360 3533322053204f6c697665205374 # "532 S Olive St" 361 a2 # map(2) 362 43 55040f # 2.5.4.15 (4) 363 6b # text(11) 364 5075626c6963205061726b # "Public Park" 365 4a 0992268993f22c640130 # 0.9.2342.19200300.100.1.48 (11) 366 6f # text(15) 367 5065727368696e6720537175617265 # "Pershing Square" 369 Figure 6: Distinguished Name, in CBOR (109 bytes) 371 (This example encoding assumes that all attribute values are UTF-8 372 strings, or can be represented as UTF-8 strings with no loss of 373 information.) 375 7. CDDL Control Operators 377 CDDL specifications may want to specify the use of SDNVs or SDNV 378 sequences (as defined for the tag content for TBD110). This document 379 introduces two new control operators that can be applied to a target 380 value that is a byte string: 382 * ".sdnv", with a control type that contains unsigned integers. The 383 byte string is specified to be encoded as an [RFC6256] SDNV (BER 384 encoding) for the matching values of the control type. 386 * ".sdnvseq", with a control type that contains arrays of unsigned 387 integers. The byte string is specified to be encoded as a 388 sequence of [RFC6256] SDNVs (BER encoding) that decodes to an 389 array of unsigned integers matching the control type. 391 * ".oid", like ".sdnvseq", except that the X*40+Y translation for 392 absolute OIDs is included (see Figure 8). 394 Figure 7 shows an example for the use of ".sdnvseq" for a part of a 395 structure using OIDs that could be used in Figure 6; Figure 8 shows 396 the same with the ".oid" operator. 398 country-rdn = {country-oid => country-value} 399 country-oid = bytes .sdnvseq [85, 4, 6] 400 country-value = text .size 2 402 Figure 7: Using .sdnvseq 404 country-rdn = {country-oid => country-value} 405 country-oid = bytes .oid [2, 5, 4, 6] 406 country-value = text .size 2 408 Figure 8: Using .oid 410 (Note that the control type need not be a literal; e.g., "bytes .oid 411 [2, 5, 4, *uint]" matches all OIDs inside OID arc 2.5.4, 412 "attributeType".) 414 8. IANA Considerations 416 8.1. CBOR Tags 418 IANA is requested to assign the CBOR tags in Table 2, with the 419 present document as the specification reference. 421 +========+================+============================+ 422 | Tag | Data Item | Semantics | 423 +========+================+============================+ 424 | TBD111 | byte string or | object identifier (BER | 425 | | array or map | encoding) | 426 +--------+----------------+----------------------------+ 427 | TBD110 | byte string or | relative object identifier | 428 | | array or map | (BER encoding); | 429 | | | SDNV [RFC6256] sequence | 430 +--------+----------------+----------------------------+ 432 Table 2: Values for New Tags 434 8.2. CDDL Control Operators 436 IANA is requested to assign the CDDL Control Operators in Table 3, 437 with the present document as the specification reference. 439 +==========+============================+ 440 | Name | Reference | 441 +==========+============================+ 442 | .sdnv | [this document, Section 7] | 443 +----------+----------------------------+ 444 | .sdnvseq | [this document, Section 7] | 445 +----------+----------------------------+ 446 | .oid | [this document, Section 7] | 447 +----------+----------------------------+ 449 Table 3: New CDDL Operators 451 9. Security Considerations 453 The security considerations of [I-D.ietf-cbor-7049bis] apply. 455 The encodings in Clauses 8.19 and 8.20 of [X.690] are quite compact 456 and unambiguous, but MUST be followed precisely to avoid security 457 pitfalls. In particular, the requirements set out in Section 2.1 of 458 this document need to be followed; otherwise, an attacker may be able 459 to subvert a checking process by submitting alternative 460 representations that are later taken as the original (or even 461 something else entirely) by another decoder supposed to be protected 462 by the checking process. 464 OIDs and relative OIDs can always be treated as opaque byte strings. 465 Actually understanding the structure that was used for generating 466 them is not necessary, and, except for checking the structure 467 requirements, it is strongly NOT RECOMMENDED to perform any 468 processing of this kind (e.g., converting into dotted notation and 469 back) unless absolutely necessary. If the OIDs are translated into 470 other representations, the usual security considerations for non- 471 trivial representation conversions apply; the integer values are 472 unlimited in range. 474 9.1. Conversions Between BER and Dotted Decimal Notation 476 [PKILCAKE] uncovers exploit vectors for the illegal values above, as 477 well as for cases in which conversion to or from the dotted decimal 478 notation goes awry. Neither [X.660] nor [X.680] place an upper bound 479 on the range of unsigned integer values for an arc; the integers are 480 arbitrarily valued. An implementation SHOULD NOT attempt to convert 481 each component using a fixed-size accumulator, as an attacker will 482 certainly be able to cause the accumulator to overflow. Compact and 483 efficient techniques for such conversions, such as the double dabble 484 algorithm [DOUBLEDABBLE] are well-known in the art; their application 485 to this field is left as an exercise to the reader. 487 10. References 489 10.1. Normative References 491 [I-D.ietf-cbor-7049bis] 492 Bormann, C. and P. Hoffman, "Concise Binary Object 493 Representation (CBOR)", Work in Progress, Internet-Draft, 494 draft-ietf-cbor-7049bis-15, 24 September 2020, 495 . 498 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 499 Requirement Levels", BCP 14, RFC 2119, 500 DOI 10.17487/RFC2119, March 1997, 501 . 503 [RFC6256] Eddy, W. and E. Davies, "Using Self-Delimiting Numeric 504 Values in Protocols", RFC 6256, DOI 10.17487/RFC6256, May 505 2011, . 507 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 508 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 509 May 2017, . 511 [X.660] International Telecommunications Union, "Information 512 technology — Procedures for the operation of object 513 identifier registration authorities: General procedures 514 and top arcs of the international object identifier tree", 515 ITU-T Recommendation X.660, July 2011. 517 [X.680] International Telecommunications Union, "Information 518 technology — Abstract Syntax Notation One (ASN.1): 519 Specification of basic notation", ITU-T Recommendation 520 X.680, August 2015. 522 [X.690] International Telecommunications Union, "Information 523 technology — ASN.1 encoding rules: Specification of Basic 524 Encoding Rules (BER), Canonical Encoding Rules (CER) and 525 Distinguished Encoding Rules (DER)", ITU-T Recommendation 526 X.690, August 2015. 528 10.2. Informative References 530 [DOUBLEDABBLE] 531 Gao, S., Al-Khalili, D., and N. Chabini, "An improved BCD 532 adder using 6-LUT FPGAs", 10th IEEE International 533 NEWCAS Conference, DOI 10.1109/newcas.2012.6328944, June 534 2012, . 536 [OID-INFO] Orange SA, "OID Repository", 2016, 537 . 539 [PCRE] Ho, A., "PCRE - Perl Compatible Regular Expressions", 540 2018, . 542 [PKILCAKE] Kaminsky, D., Patterson, M., and L. Sassaman, "PKI Layer 543 Cake: New Collision Attacks against the Global X.509 544 Infrastructure", Financial Cryptography and Data 545 Security pp. 289-303, DOI 10.1007/978-3-642-14577-3_22, 546 2010, . 548 [RFC7388] Schoenwaelder, J., Sehgal, A., Tsou, T., and C. Zhou, 549 "Definition of Managed Objects for IPv6 over Low-Power 550 Wireless Personal Area Networks (6LoWPANs)", RFC 7388, 551 DOI 10.17487/RFC7388, October 2014, 552 . 554 [X.672] International Telecommunications Union, "Information 555 technology — Open systems interconnection — Object 556 identifier resolution system", ITU-T Recommendation X.672, 557 August 2010. 559 Appendix A. Change Log 561 This section is to be removed before publishing as an RFC. 563 A.1. Changes from -07 (bormann) to -00 (ietf) 565 Resubmitted as WG draft after adoption. 567 A.2. Changes from -06 to -07 569 Reduce the draft back to its basic mandate: Describe CBOR tags for 570 what is colloquially know as ASN.1 Object IDs. 572 A.3. Changes from -05 to -06 574 Refreshed the draft to the current date ("keep-alive"). 576 A.4. Changes from -04 to -05 578 Discussed UUID usage in CBOR, and incorporated fixes proposed by 579 Olivier Dubuisson, including fixes regarding OID nomenclature. 581 A.5. Changes from -03 to -04 583 Changes occurred based on limited feedback, mainly centered around 584 the abstract and introduction, rather than substantive technical 585 changes. These changes include: 587 * Changed the title so that it is about tags and techniques. 589 * Rewrote the abstract to describe the content more accurately, and 590 to point out that no changes to the wire protocol are being 591 proposed. 593 * Removed "ASN.1" from "object identifiers", as OIDs are independent 594 of ASN.1. 596 * Rewrote the introduction to be more about the present text. 598 * Proposed a concise OID arc. 600 * Provided binary regular expression forms for OID validation. 602 * Updated IANA registration tables. 604 A.6. Changes from -02 to -03 606 Many significant changes occurred in this version. These changes 607 include: 609 * Expanded the draft scope to be a comprehensive CBOR update. 611 * Added OID-related sections: OID Enumerations, OID Maps and Arrays, 612 and Applications and Examples of OIDs. 614 * Added Tag 36 update (binary MIME, better definitions). 616 * Added stub/experimental sections for X.690 Series Tags (tag <>) 617 and Regular Expressions (tag 35). 619 * Added technique for representing sets and multisets. 621 * Added references and fixed typos. 623 Acknowledgments 625 Jim Schaad provided a review of this document. 627 Authors' Addresses 629 Carsten Bormann 630 Universität Bremen TZI 631 Postfach 330440 632 D-28359 Bremen 633 Germany 635 Phone: +49-421-218-63921 636 Email: cabo@tzi.org 638 Sean Leonard 639 Penango, Inc. 640 5900 Wilshire Boulevard 641 21st Floor 642 Los Angeles, CA, 90036 643 United States of America 645 Email: dev+ietf@seantek.com 646 URI: http://www.penango.com/