idnits 2.17.1 draft-ietf-cbor-tags-oid-00.txt: -(3): 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 2 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 (31 July 2020) is 1363 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 394 -- Looks like a reference, but probably isn't: '4' on line 400 -- Looks like a reference, but probably isn't: '6' on line 400 -- Looks like a reference, but probably isn't: '2' on line 400 -- Looks like a reference, but probably isn't: '5' on line 400 == Outdated reference: A later version (-16) exists of draft-ietf-cbor-7049bis-14 -- 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: 1 February 2021 Penango, Inc. 6 31 July 2020 8 Concise Binary Object Representation (CBOR) Tags for Object Identifiers 9 draft-ietf-cbor-tags-oid-00 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 1 February 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 . . . . . . . . . . . . . . . . . . . . . 13 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: 146 Tag TBD111: tags a byte string as the [X.690] encoding of an absolute 147 object identifier (simply "object identifier" or "OID"). 149 Tag TBD110: tags a byte string as the [X.690] encoding of a relative 150 object identifier (also "relative OID"). Since the encoding of each 151 number is the same as for [RFC6256] Self-Delimiting Numeric Values 152 (SDNVs), this tag can also be used for tagging a byte string that 153 contains a sequence of zero or more SDNVs. 155 2.1. Requirements on the byte string being tagged 157 To form a valid tag, a byte string tagged by TBD111 or TBD110 MUST be 158 a syntactically valid BER representation of an object identifier: A 159 concatenation of zero or more SDNV values, where each SDNV value is a 160 sequence of one or more bytes that all have their most significant 161 bit set, except for the last byte, where it must be unset; the first 162 byte of each SDNV cannot be 0x80 (which would be a leading zero in 163 SDNV's base-128 arithmetic). 165 In other words: 167 * its first byte, and any byte that follows a byte that has the most 168 significant bit unset, MUST NOT be 0x80 (this requirement requires 169 expressing the integer values in their shortest form, with no 170 leading zeroes) 172 * its last byte MUST NOT have the most significant bit set (this 173 requirement excludes an incomplete final integer value) 175 If either of these invalid conditions are encountered, the tag is 176 invalid. 178 [X.680] restricts RELATIVE-OID values to have at least one arc, i.e., 179 their encoding would have at least one SDNV. This specification 180 permits empty relative object identifiers; they may still be excluded 181 by application semantics. 183 To facilitate the search for specific object ID values, it is 184 RECOMMENDED that definite length encoding (see Section 3.2.3 of 185 [I-D.ietf-cbor-7049bis]) is used for the byte strings used as tag 186 content for these tags. 188 The valid set of byte strings can also be expressed using regular 189 expressions on bytes, using no specific notation but resembling 190 [PCRE]. Unlike typical regular expressions that operate on character 191 sequences, the following regular expressions take bytes as their 192 domain, so they can be applied directly to CBOR byte strings. 194 For byte strings with tag TBD111: 196 "/^(([\x81-\xFF][\x80-\xFF]*)?[\x00-\x7F])+$/" 198 For byte strings with tag TBD110: 200 "/^(([\x81-\xFF][\x80-\xFF]*)?[\x00-\x7F])*$/" 202 A tag with tagged content that does not conform to the applicable 203 regexp is invalid. 205 3. Examples 207 3.1. Encoding of the SHA-256 OID 209 ASN.1 Value Notation: { joint-iso-itu-t(2) country(16) us(840) 210 organization(1) gov(101) csor(3) nistalgorithm(4) hashalgs(2) 211 sha256(1) } 213 Dotted Decimal Notation: 2.16.840.1.101.3.4.2.1 215 06 # UNIVERSAL TAG 6 216 09 # 9 bytes, primitive 217 60 86 48 01 65 03 04 02 01 # X.690 Clause 8.19 218 # | 840 1 | 3 4 2 1 show component encoding 219 # 2.16 101 221 Figure 1: SHA-256 OID in BER 223 D8 6F # tag(111) 224 49 # 0b010_01001: mt 2, 9 bytes 225 60 86 48 01 65 03 04 02 01 # X.690 Clause 8.19 227 Figure 2: SHA-256 OID in CBOR 229 3.2. Encoding of a MIB Relative OID 231 Given some OID (e.g., "lowpanMib", assumed to be "1.3.6.1.2.1.226" 232 [RFC7388]), to which the following is added: 234 ASN.1 Value Notation: { lowpanObjects(1) lowpanStats(1) 235 lowpanOutTransmits(29) } 237 Dotted Decimal Notation: .1.1.29 239 0D # UNIVERSAL TAG 13 240 03 # 3 bytes, primitive 241 01 01 1D # X.690 Clause 8.20 242 # 1 1 29 show component encoding 244 Figure 3: MIB relative object identifier, in BER 246 D8 6E # tag(110) 247 43 # 0b010_01001: mt 2 (bstr), 3 bytes 248 01 01 1D # X.690 Clause 8.20 250 Figure 4: MIB relative object identifier, in CBOR 252 This relative OID saves seven bytes compared to the full OID 253 encoding. 255 4. Discussion 257 Staying close to the way object identifiers are encoded in ASN.1 BER 258 makes back-and-forth translation easy; otherwise we would choose a 259 more efficient encoding. Object identifiers in IETF protocols are 260 serialized in dotted decimal form or BER form, so there is an 261 advantage in not inventing a third form. Also, expectations of the 262 cost of encoding object identifiers are based on BER; using a 263 different encoding might not be aligned with these expectations. If 264 additional information about an OID is desired, lookup services such 265 as the OID Resolution Service (ORS) [X.672] and the OID Repository 266 [OID-INFO] are available. 268 5. Tag Factoring with OID Arrays and Maps 270 TBD111 and TBD110 can tag CBOR arrays and maps. The idea is that the 271 tag is factored out from each individual byte string; the tag is 272 placed in front of the array or map instead. The tags TBD111 and 273 TBD110 are left-distributive. 275 When the TBD111 or TBD110 tag is applied to an array, it means that 276 the respective tag is imputed to all items in the array that are byte 277 strings. For example, when the array is tagged with TBD111, every 278 array item that is a binary string is an OID. 280 When the TBD111 or TBD110 tag is applied to a map, it means that the 281 respective tag is imputed to all keys in the map that are byte 282 strings. The values in the map are not considered specially tagged. 284 Array and map nesting is permitted. For example, a 3-dimensional 285 array of OIDs can be composed by using a single TBD111 tag, followed 286 by an array of arrays of arrays of binary strings. All such binary 287 strings are considered OIDs. 288 // That was part of the original proposal. I find it hard to imagine 289 // how to stop the influence of the tag deep into a nested structure. 290 // That's why I would rather limit this to one level (no nesting). 291 // But see the Figure below, which needs a nesting of two. Please 292 // discuss. 294 6. Applications and Examples of OIDs 296 6.1. X.500 Distinguished Name 298 Consider the X.500 distinguished name: 300 +==============================+=============+ 301 | Attribute Types | Attribute | 302 | | Values | 303 +==============================+=============+ 304 | c (2.5.4.6) | US | 305 +------------------------------+-------------+ 306 | l (2.5.4.7) | Los Angeles | 307 | s (2.5.4.8) | CA | 308 | postalCode (2.5.4.17) | 90013 | 309 +------------------------------+-------------+ 310 | street (2.5.4.9) | 532 S Olive | 311 | | St | 312 +------------------------------+-------------+ 313 | businessCategory (2.5.4.15) | Public Park | 314 | buildingName | Pershing | 315 | (0.9.2342.19200300.100.1.48) | Square | 316 +------------------------------+-------------+ 318 Table 1: Example X.500 Distinguished Name 320 Table 1 has four "relative distinguished names" (RDNs). The country 321 and street RDNs are single-valued. The second and fourth RDNs are 322 multi-valued. 324 The equivalent representations in CBOR diagnostic notation and CBOR 325 are: 327 111([{ h'550406': "US" }, 328 { h'550407': "Los Angeles", h'550408': "CA", 329 h'550411': "90013" }, 330 { h'550409': "532 S Olive St" }, 331 { h'55040f': "Public Park", 332 h'0992268993f22c640130': "Pershing Square" }]) 334 Figure 5: Distinguished Name, in CBOR Diagnostic Notation 336 d8 6f # tag(111) 337 84 # array(4) 338 a1 # map(1) 339 43 550406 # 2.5.4.6 (4) 340 62 # text(2) 341 5553 # "US" 342 a3 # map(3) 343 43 550407 # 2.5.4.7 (4) 344 6b # text(11) 345 4c6f7320416e67656c6573 # "Los Angeles" 346 43 550408 # 2.5.4.8 (4) 347 62 # text(2) 348 4341 # "CA" 349 43 550411 # 2.5.4.17 (4) 350 65 # text(5) 351 3930303133 # "90013" 352 a1 # map(1) 353 43 550409 # 2.5.4.9 (4) 354 6e # text(14) 355 3533322053204f6c697665205374 # "532 S Olive St" 356 a2 # map(2) 357 43 55040f # 2.5.4.15 (4) 358 6b # text(11) 359 5075626c6963205061726b # "Public Park" 360 4a 0992268993f22c640130 # 0.9.2342.19200300.100.1.48 (11) 361 6f # text(15) 362 5065727368696e6720537175617265 # "Pershing Square" 364 Figure 6: Distinguished Name, in CBOR (109 bytes) 366 (This example encoding assumes that all attribute values are UTF-8 367 strings, or can be represented as UTF-8 strings with no loss of 368 information.) 370 7. CDDL Control Operators 372 CDDL specifications may want to specify the use of SDNVs or SDNV 373 sequences (as defined for the tag content for TBD110). This document 374 introduces two new control operators that can be applied to a target 375 value that is a byte string: 377 * ".sdnv", with a control type that contains unsigned integers. The 378 byte string is specified to be encoded as an [RFC6256] SDNV (BER 379 encoding) for the matching values of the control type. 381 * ".sdnvseq", with a control type that contains arrays of unsigned 382 integers. The byte string is specified to be encoded as a 383 sequence of [RFC6256] SDNVs (BER encoding) that decodes to an 384 array of unsigned integers matching the control type. 386 * ".oid", like ".sdnvseq", except that the X*40+Y translation for 387 absolute OIDs is included (see Figure 8). 389 Figure 7 shows an example for the use of ".sdnvseq" for a part of a 390 structure using OIDs that could be used in Figure 6; Figure 8 shows 391 the same with the ".oid" operator. 393 country-rdn = {country-oid => country-value} 394 country-oid = bytes .sdnvseq [85, 4, 6] 395 country-value = text .size 2 397 Figure 7: Using .sdnvseq 399 country-rdn = {country-oid => country-value} 400 country-oid = bytes .oid [2, 5, 4, 6] 401 country-value = text .size 2 403 Figure 8: Using .oid 405 (Note that the control type need not be a literal; e.g., "bytes .oid 406 [2, 5, 4, *uint]" matches all OIDs inside OID arc 2.5.4, 407 "attributeType".) 409 8. IANA Considerations 411 8.1. CBOR Tags 413 IANA is requested to assign the CBOR tags in Table 2, with the 414 present document as the specification reference. 416 +========+===========+============================================+ 417 | Tag | Data Item | Semantics | 418 +========+===========+============================================+ 419 | TBD111 | multiple | object identifier (BER encoding) | 420 +--------+-----------+--------------------------------------------+ 421 | TBD110 | multiple | relative object identifier (BER encoding); | 422 | | | SDNV [RFC6256] sequence | 423 +--------+-----------+--------------------------------------------+ 425 Table 2: Values for New Tags 427 8.2. CDDL Control Operators 429 IANA is requested to assign the CDDL Control Operators in Table 3, 430 with the present document as the specification reference. 432 +==========+============================+ 433 | Name | Reference | 434 +==========+============================+ 435 | .sdnv | [this document, Section 7] | 436 +----------+----------------------------+ 437 | .sdnvseq | [this document, Section 7] | 438 +----------+----------------------------+ 439 | .oid | [this document, Section 7] | 440 +----------+----------------------------+ 442 Table 3: New CDDL Operators 444 9. Security Considerations 446 The security considerations of [I-D.ietf-cbor-7049bis] apply. 448 The encodings in Clauses 8.19 and 8.20 of [X.690] are quite compact 449 and unambiguous, but MUST be followed precisely to avoid security 450 pitfalls. In particular, the requirements set out in Section 2.1 of 451 this document need to be followed; otherwise, an attacker may be able 452 to subvert a checking process by submitting alternative 453 representations that are later taken as the original (or even 454 something else entirely) by another decoder supposed to be protected 455 by the checking process. 457 OIDs and relative OIDs can always be treated as opaque byte strings. 458 Actually understanding the structure that was used for generating 459 them is not necessary, and, except for checking the structure 460 requirements, it is strongly NOT RECOMMENDED to perform any 461 processing of this kind (e.g., converting into dotted notation and 462 back) unless absolutely necessary. If the OIDs are translated into 463 other representations, the usual security considerations for non- 464 trivial representation conversions apply; the integer values are 465 unlimited in range. 467 9.1. Conversions Between BER and Dotted Decimal Notation 469 [PKILCAKE] uncovers exploit vectors for the illegal values above, as 470 well as for cases in which conversion to or from the dotted decimal 471 notation goes awry. Neither [X.660] nor [X.680] place an upper bound 472 on the range of unsigned integer values for an arc; the integers are 473 arbitrarily valued. An implementation SHOULD NOT attempt to convert 474 each component using a fixed-size accumulator, as an attacker will 475 certainly be able to cause the accumulator to overflow. Compact and 476 efficient techniques for such conversions, such as the double dabble 477 algorithm [DOUBLEDABBLE] are well-known in the art; their application 478 to this field is left as an exercise to the reader. 480 10. References 482 10.1. Normative References 484 [I-D.ietf-cbor-7049bis] 485 Bormann, C. and P. Hoffman, "Concise Binary Object 486 Representation (CBOR)", Work in Progress, Internet-Draft, 487 draft-ietf-cbor-7049bis-14, 16 June 2020, 488 . 491 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 492 Requirement Levels", BCP 14, RFC 2119, 493 DOI 10.17487/RFC2119, March 1997, 494 . 496 [RFC6256] Eddy, W. and E. Davies, "Using Self-Delimiting Numeric 497 Values in Protocols", RFC 6256, DOI 10.17487/RFC6256, May 498 2011, . 500 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 501 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 502 May 2017, . 504 [X.660] International Telecommunications Union, "Information 505 technology -- Procedures for the operation of object 506 identifier registration authorities: General procedures 507 and top arcs of the international object identifier tree", 508 ITU-T Recommendation X.660, July 2011. 510 [X.680] International Telecommunications Union, "Information 511 technology -- Abstract Syntax Notation One (ASN.1): 512 Specification of basic notation", ITU-T Recommendation 513 X.680, August 2015. 515 [X.690] International Telecommunications Union, "Information 516 technology -- ASN.1 encoding rules: Specification of Basic 517 Encoding Rules (BER), Canonical Encoding Rules (CER) and 518 Distinguished Encoding Rules (DER)", ITU-T Recommendation 519 X.690, August 2015. 521 10.2. Informative References 523 [DOUBLEDABBLE] 524 Gao, S., Al-Khalili, D., and N. Chabini, "An improved BCD 525 adder using 6-LUT FPGAs", DOI 10.1109/newcas.2012.6328944, 526 10th IEEE International NEWCAS Conference, June 2012, 527 . 529 [OID-INFO] Orange SA, "OID Repository", 2016, 530 . 532 [PCRE] Ho, A., "PCRE - Perl Compatible Regular Expressions", 533 2018, . 535 [PKILCAKE] Kaminsky, D., Patterson, M., and L. Sassaman, "PKI Layer 536 Cake: New Collision Attacks against the Global X.509 537 Infrastructure", DOI 10.1007/978-3-642-14577-3_22, 538 Financial Cryptography and Data Security pp. 289-303, 539 2010, . 541 [RFC7388] Schoenwaelder, J., Sehgal, A., Tsou, T., and C. Zhou, 542 "Definition of Managed Objects for IPv6 over Low-Power 543 Wireless Personal Area Networks (6LoWPANs)", RFC 7388, 544 DOI 10.17487/RFC7388, October 2014, 545 . 547 [X.672] International Telecommunications Union, "Information 548 technology -- Open systems interconnection -- Object 549 identifier resolution system", ITU-T Recommendation X.672, 550 August 2010. 552 Appendix A. Change Log 554 This section is to be removed before publishing as an RFC. 556 A.1. Changes from -07 (bormann) to -00 (ietf) 558 Resubmitted as WG draft after adoption. 560 A.2. Changes from -06 to -07 562 Reduce the draft back to its basic mandate: Describe CBOR tags for 563 what is colloquially know as ASN.1 Object IDs. 565 A.3. Changes from -05 to -06 567 Refreshed the draft to the current date ("keep-alive"). 569 A.4. Changes from -04 to -05 571 Discussed UUID usage in CBOR, and incorporated fixes proposed by 572 Olivier Dubuisson, including fixes regarding OID nomenclature. 574 A.5. Changes from -03 to -04 576 Changes occurred based on limited feedback, mainly centered around 577 the abstract and introduction, rather than substantive technical 578 changes. These changes include: 580 * Changed the title so that it is about tags and techniques. 582 * Rewrote the abstract to describe the content more accurately, and 583 to point out that no changes to the wire protocol are being 584 proposed. 586 * Removed "ASN.1" from "object identifiers", as OIDs are independent 587 of ASN.1. 589 * Rewrote the introduction to be more about the present text. 591 * Proposed a concise OID arc. 593 * Provided binary regular expression forms for OID validation. 595 * Updated IANA registration tables. 597 A.6. Changes from -02 to -03 599 Many significant changes occurred in this version. These changes 600 include: 602 * Expanded the draft scope to be a comprehensive CBOR update. 604 * Added OID-related sections: OID Enumerations, OID Maps and Arrays, 605 and Applications and Examples of OIDs. 607 * Added Tag 36 update (binary MIME, better definitions). 609 * Added stub/experimental sections for X.690 Series Tags (tag <>) 610 and Regular Expressions (tag 35). 612 * Added technique for representing sets and multisets. 614 * Added references and fixed typos. 616 Acknowledgments 618 Jim Schaad provided a review of this document. 620 Authors' Addresses 622 Carsten Bormann 623 Universität Bremen TZI 624 Postfach 330440 625 D-28359 Bremen 626 Germany 628 Phone: +49-421-218-63921 629 Email: cabo@tzi.org 631 Sean Leonard 632 Penango, Inc. 633 5900 Wilshire Boulevard 634 21st Floor 635 Los Angeles, CA, 90036 636 United States of America 638 Email: dev+ietf@seantek.com 639 URI: http://www.penango.com/