idnits 2.17.1 draft-bormann-cbor-tags-oid-03.txt: 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: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 13 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 (June 30, 2016) is 2858 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) ** Obsolete normative reference: RFC 7049 (Obsoleted by RFC 8949) ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Bormann 3 Internet-Draft Universitaet Bremen TZI 4 Intended status: Standards Track S. Leonard 5 Expires: January 1, 2017 Penango, Inc. 6 June 30, 2016 8 Concise Binary Object Representation (CBOR) Tags for 9 ASN.1 Object Identifiers, and Omnibus Corrections and Techniques 10 draft-bormann-cbor-tags-oid-03 12 Abstract 14 The Concise Binary Object Representation (CBOR, RFC 7049) is a data 15 format whose design goals include the possibility of extremely small 16 code size, fairly small message size, and extensibility without the 17 need for version negotiation. 19 The present document makes use of this extensibility to define CBOR 20 tags <> and <> [values TBD] for ASN.1 object identifiers. It 21 is intended as the reference document for the IANA registration of 22 the CBOR tags so defined. This document also provides other 23 corrections and improvements to CBOR. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on January 1, 2017. 42 Copyright Notice 44 Copyright (c) 2016 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. ASN.1 Object Identifiers . . . . . . . . . . . . . . . . . . 3 61 3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 5. Diagnostic Notation . . . . . . . . . . . . . . . . . . . . . 7 64 6. Enumerations in CBOR . . . . . . . . . . . . . . . . . . . . 8 65 7. Tag Factoring and Tag Stacking with OID Arrays and Maps . . . 11 66 8. Applications and Examples of OIDs . . . . . . . . . . . . . . 15 67 9. Binary Internet Messages and MIME Entities . . . . . . . . . 18 68 10. Applications and Examples of Messages and Entities . . . . . 21 69 11. X.690 Series Tags . . . . . . . . . . . . . . . . . . . . . . 21 70 12. Regular Expression Clarification . . . . . . . . . . . . . . 22 71 13. Set and Multiset Technique . . . . . . . . . . . . . . . . . 23 72 14. Fruits Basket Example . . . . . . . . . . . . . . . . . . . . 23 73 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 74 16. Security Considerations . . . . . . . . . . . . . . . . . . . 25 75 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 76 Appendix A. Changes from -02 to -03 . . . . . . . . . . . . . . 28 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 79 1. Introduction 81 The Concise Binary Object Representation (CBOR, [RFC7049]) provides 82 for the interchange of structured data without a requirement for a 83 pre-agreed schema. RFC 7049 defines a basic set of data types, as 84 well as a tagging mechanism that enables extending the set of data 85 types supported via an IANA registry. 87 Many IETF protocols carry ASN.1 object identifiers, originally 88 defined in 1988 [CCITT.X208.1988] and most recently in 2015 [X.680]. 89 The ASN.1 Basic Encoding Rules (BER, [X.690]) specify the binary 90 encodings of both ASN.1 object identifiers and relative object 91 identifiers. The contents of these encodings can be carried in a 92 CBOR byte string. 94 This document defines two CBOR tags that cover the two kinds of ASN.1 95 object identifiers encoded in this way. It is intended as the 96 reference document for the IANA registration of the tags so defined. 98 During development of this Internet-Draft, a couple of deficiencies 99 and points of enhancement were noted. This document updates 100 [RFC7049] to handle binary Internet messages natively, and provides 101 certain techniques for efficiently encoding sets in CBOR. 103 1.1. Terminology 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 107 "OPTIONAL" in this document are to be interpreted as described in RFC 108 2119 [RFC2119]. 110 The terminology of RFC 7049 applies; in particular the term "byte" is 111 used in its now customary sense as a synonym for "octet". 113 2. ASN.1 Object Identifiers 115 The International Object Identifier tree [X.660] is a hierarchically 116 managed space of identifiers, each of which is uniquely represented 117 as a sequence of unsigned integers ("sub-identifiers") [X.680]. 118 While these sequences can easily be represented in CBOR arrays of 119 unsigned integers, a more compact representation can often be 120 achieved by adopting the widely used representation of ASN.1 object 121 identifiers defined in BER; this representation may also be more 122 amenable to processing by other software making use of ASN.1 object 123 identifiers. 125 BER represents the sequence of unsigned integers by concatenating 126 self-delimiting [RFC6256] representations of each of the sub- 127 identifiers in sequence. 129 ASN.1 distinguishes absolute object identifiers (ASN.1 Type 130 "OBJECT IDENTIFIER"), which begin at a root arc ([X.660] Clause 131 3.5.21), from relative object identifiers (ASN.1 Type "RELATIVE- 132 OID"), which begin relative to some object identifier known from 133 context ([X.680] Clause 3.8.63). As a special optimization, BER 134 combines the first two integers in an absolute object identifier into 135 one numeric identifier by making use of the property of the hierarchy 136 that the first arc has only three integer values (0, 1, and 2), and 137 the second arcs under 0 and 1 are limited to the integer values 138 between 0 and 39. (The root arc "joint-iso-itu-t(2)" has no such 139 limitations on its second arc.) If X and Y are the first two 140 integers, the single integer actually encoded is computed as: 142 X * 40 + Y 144 The inverse transformation (again making use of the known ranges of X 145 and Y) is applied when decoding the ASN.1 object identifier. 147 Since the semantics of absolute and relative object identifiers 148 differ, this specification defines two tags: 150 Tag <> (value TBD): tags a byte string as the ASN.1 BER encoding 151 of an absolute object identifier (simply "object identifier" or 152 "OID"). 154 Tag <> (value TBD): tags a byte string as the ASN.1 BER encoding 155 of a relative object identifier (also "relative OID"). 157 2.1. Requirements on the byte string being tagged 159 A byte string tagged by <> or <> MUST be a syntactically valid 160 BER representation of an ASN.1 object identifier. Specifically: 162 o its first byte, and any byte that follows a byte that has the most 163 significant bit unset, MUST NOT be 0x80 (this requirement excludes 164 expressing the sub-identifiers with anything but the shortest 165 form) 167 o its last byte MUST NOT have the most significant bit set (this 168 requirement excludes an incomplete final sub-identifier) 170 If either of these invalid conditions are encountered, they MUST be 171 treated as decoding errors. Comparing two OIDs or relative OIDs for 172 equality in a byte-for-byte fashion may not be safe before these 173 checks succeed on at least one of them (this includes the case where 174 one of them is a local constant); a process implementing an exclusion 175 list MUST check for decoding errors first. 177 [X.680] restricts RELATIVE-OID values to have at least one sub- 178 identifier (array element). This specification permits empty 179 relative object identifiers; they may still be excluded by 180 application semantics. 182 [RFC7049] permits byte strings to be indefinite-length, with chunks 183 divided at arbitrary byte boundaries. This contrasts with text 184 strings, where each chunk in an indefinite-length text string is 185 required be well-formed UTF-8 on its own: splitting the octets of a 186 UTF-8 character encoding between chunks is not allowed. 188 By analogy to this principle and to Clauses 8.9.1 and 8.20.1 of 189 [X.690], the byte strings carrying the OIDs and relative OIDs are 190 also to be treated as indivisible units: They MUST be encoded in 191 definite-length form; indefinite-length form is treated as an 192 encoding error (and the same considerations as above apply). (An 193 added convenience is that CBOR encodings can be searched through 194 efficiently for specific OIDs or relative OIDs, without initiating 195 the decoding process.) 197 3. Examples 199 In the following examples, we are using tag number 6 for <> and 200 tag number 7 for <>. See Section 15.2. 202 3.1. Encoding of the SHA-256 OID 204 ASN.1 Value Notation 205 { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 206 csor(3) nistalgorithm(4) hashalgs(2) sha256(1) } 208 Dotted Decimal Notation (also XML Value Notation) 209 2.16.840.1.101.3.4.2.1 211 06 # UNIVERSAL TAG 6 212 09 # 9 bytes, primitive 213 60 86 48 01 65 03 04 02 01 # X.690 Clause 8.19 214 # | 840 1 | 3 4 2 1 show component encoding 215 # 2.16 101 217 Figure 1: SHA-256 OID in BER 219 C6 # 0b110_00110: mt 6, tag 6 220 49 # 0b010_01001: mt 2, 9 bytes 221 60 86 48 01 65 03 04 02 01 # X.690 Clause 8.19 223 Figure 2: SHA-256 OID in CBOR 225 3.2. Encoding of a UUID OID 227 UUID 228 8b0d1a20-dcc5-11d9-bda9-0002a5d5c51b 230 ASN.1 Value Notation 231 { joint-iso-itu-t(2) uuid(25) 232 geomicaGPAS(184830721219540099336690027854602552603) } 234 Dotted Decimal Notation (also XML Value Notation) 235 2.25.184830721219540099336690027854602552603 236 06 # UNIVERSAL TAG 6 237 14 # 20 bytes, primitive 238 69 82 96 8D 8D 88 9B CC A8 C7 B3 BD D4 C0 80 AA AE D7 8A 1B 239 # | 184830721219540099336690027854602552603 240 # 2.25 242 Figure 3: UUID in an object identifier, in BER 244 C6 # 0b110_00110: mt 6, tag 6 245 54 # 0b010_10100: mt 2, 20 bytes 246 69 82 96 8D 8D 88 9B CC A8 C7 B3 BD D4 C0 80 AA AE D7 8A 1B 248 Figure 4: UUID in an object identifier, in CBOR 250 3.3. Encoding of a MIB Relative OID 252 Given some OID (e.g., "lowpanMib", assumed to be "1.3.6.1.2.1.226" 253 [RFC7388]), to which the following is added: 255 ASN.1 Value Notation (not suitable for diagnostic notation) 256 { lowpanObjects(1) lowpanStats(1) lowpanOutTransmits(29) } 258 Dotted Decimal Notation (diagnostic notation; see Section 5) 259 .1.1.29 261 0D # UNIVERSAL TAG 13 262 03 # 3 bytes, primitive 263 01 01 1D # X.690 Clause 8.20 264 # 1 1 29 show component encoding 266 Figure 5: MIB relative object identifier, in BER 268 C7 # 0b110_00110: mt 6, tag 7 269 43 # 0b010_01001: mt 2 (bstr), 3 bytes 270 01 01 1D # X.690 Clause 8.20 272 Figure 6: MIB relative object identifier, in CBOR 274 This relative OID saves seven bytes compared to the full OID 275 encoding. 277 4. Discussion 279 Staying close to the way ASN.1 object identifiers are encoded in 280 ASN.1 BER makes back-and-forth translation easy. As of today, ASN.1 281 object identifiers are either used in dotted decimal form or BER 282 form, so there is an advantage in not inventing a third form. Also, 283 expectations of the cost of encoding ASN.1 object identifiers are 284 based on BER; using a different encoding might not be aligned with 285 these expectations. If additional information about an OID is 286 desired, lookup services such as the OID Resolution Service (ORS) 287 [X.672] and the OID Repository [OID-INFO] are available. 289 This specification allocates two numbers out of the single-byte tag 290 space. This use of code point space is justified by the wide use of 291 object identifiers in data interchange. For most common OIDs in use 292 (namely those whose contents encode to less than 24 bytes), the CBOR 293 encoding will match the efficiency of [X.690]. (This preliminary 294 conclusion is likely to generate some discussion, see Section 15.2.) 296 5. Diagnostic Notation 298 Implementers will likely want to see OIDs and relative OIDs in their 299 "natural forms" (as sequences of decimal unsigned integers) for 300 diagnostic purposes. Accordingly, this section defines additional 301 syntactic elements that can be used in conjunction with the 302 diagnostic notation described in Section 6 of [RFC7049]. 304 An object identifier may be written in ASN.1 value notation (with 305 enclosing braces and secondary identifiers, ObjectIdentifierValue of 306 Clause 32.3 of [X.680]), or in dotted decimal notation with at least 307 three arcs. Both examples are shown in Section 3. The surrounding 308 tag notation is not to be used, because the tag is implied. The 309 ASN.1 value notation for OIDs does not overlap with JSON object 310 notation for CBOR maps, because at least two arcs are required for a 311 valid OID. 313 A relative object identifier may be written in dotted decimal 314 notation or in ASN.1 value notation, in both cases prefixed with a 315 dot as shown in Section 3.3. The surrounding tag notation is not to 316 be used, because the tag is implied. 318 The notation in this section may be employed in addition to the basic 319 notation, which would be a tagged binary string. 321 +------------------------------+--------------+------------+ 322 | RFC 7049 diagnostic notation | 6(h'2b0601') | 7(h'0601') | 323 +------------------------------+--------------+------------+ 324 | Dotted decimal notation | 1.3.6.1 | .6.1 | 325 | ASN.1 value notation | {1 3 6 1} | .{6 1} | 326 +------------------------------+--------------+------------+ 328 Table 1: Examples for extended diagnostic notation 330 6. Enumerations in CBOR 332 This section provides a roadmap to using enumerated items in CBOR, 333 including design considerations for choosing between OIDs, integers, 334 and UTF-8 strings. 336 CBOR does not have an ENUMERATED type like ASN.1 to identify named 337 values in a protocol element with three or more states (Clause 20 and 338 Clause G.2.3 of [X.680]). ASN.1 ENUMERATED turns out to be 339 superfluous because ASN.1 INTEGER values can get named (and have 340 historically been used for finite, multistate variables, such as 341 version numbers), while ASN.1 ENUMERATED types can be defined to be 342 extensible with the ellipsis lexical item. Practically, the named 343 integers are not serialized in the binary encodings anyway; they 344 merely serve as a semantic hints for designers and debuggers. 346 CBOR expects that protocol designers will use one of the basic major 347 types for multistate variables, assigning semantics to particular 348 values using higher-level schemas. The obvious choices for the basic 349 types are integers (particularly unsigned integers) and UTF-8 350 strings. However, these major types are not without drawbacks. 352 Integers are compact for small values, but have a flat namespace so 353 there are mis-assignment and collision risks that can only be 354 mitigated with protocol-specific registries. Arrays of integers are 355 possible, but arrays require more processing logic for equality 356 comparisons, and the JSON conversion is not intuitive when the 357 enumerated value serves as a key in a map. 359 UTF-8 strings are less compact when the strings are supposed to 360 resemble their semantics, and there are normalization issues if the 361 strings contain characters beyond the ASCII range. UTF-8 strings 362 also comprise a flat namespace like integers unless the higher-level 363 schema employs delimiters (which makes the string even larger). This 364 section provides a novel alternative in OIDs. 366 6.1. Factors Favoring OID Enumerations 368 A protocol designer might choose OIDs or relative OIDs for an 369 enumerated item in view of the following observations: 371 1. OIDs and relative OIDs are quite compact: a single-arc relative 372 OID encoded according to this specification occupies just two 373 bytes for primary integer values 0-127 (excluding the semantic 374 tag <>), and three bytes for primary integer values 128-16383. 375 (In contrast, an unsigned integer requires one byte for 0-23, two 376 bytes for 24-255, and three bytes for 256-65535.) 378 2. OIDs and relative OIDs (with base) are persistent and globally 379 unambiguous. 381 3. OIDs and relative OIDs have built-in semantics for designers and 382 debuggers. Specifically, the advent of universal OID 383 repositories such as [OID-INFO] makes it easy for a designer or 384 debugger to pull up useful information about the object of 385 interest (Clause 3.5.10 of [X.660]). This useful information 386 (for humans) does not have to bleed into the encoded 387 representation (for machines). 389 4. OIDs and relative OIDs are always compared for exact equality: no 390 need to deal with case folding, case sensitivity, or other 391 normalization issues. ("Overlong" encodings are PROHIBITED; 392 therefore overlong encodings MUST be treated as coding errors.) 394 5. OIDs and relative OIDs have a built-in hierarchy, so if 395 implementers want to extend an enumeration without assigning new 396 values "horizontally", they have the option of assigning new 397 values "vertically", possibly with more or less stringent 398 assignment rules. 400 6. Because OIDs and relative OIDs (with base) are part of the so- 401 called International Object Identifier tree [X.660], any other 402 protocol specification can reuse the enumeration if the designers 403 find it useful. 405 7. OIDs and relative OIDs have natural JSON representations in the 406 dotted decimal notations prescribed in Section 5. OIDs and 407 relative OIDs can be distinguished from each other by the 408 presence or absence of the leading dot ".". As the resulting 409 JSON string is entirely numeric in the ASCII range, case and 410 normalization are irrelevant to the comparison. (An object 411 identifier also has a semantic string representation in the form 412 of an OID-IRI [X.680], for those who really want that type of 413 thing.) 415 8. OIDs and relative OIDs are human language-neutral. A protocol 416 designer working in US-English might name an enumerated value 417 "sig" for "signature", but "sig" could also stand for 418 "significand", "signal", or "special interest group". In Swedish 419 and Norwegian, "sig" is a pronoun that means "himself, herself, 420 itself, one, them", etc.--an entirely different meaning. 422 6.2. Factors Favoring Integer Enumerations 424 A protocol designer might choose integers for an enumerated item in 425 view of the following observations: 427 1. The CBOR encoding of unsigned integers 0-23 is the most compact, 428 occupying exactly one byte (excluding any semantic tags). 430 2. A protocol designer may wish to prohibit extensibility as a 431 matter of course. Integers comprise a single flat namespace: 432 there is no hierarchy. 434 3. If greater range is desired while sticking to one byte, a 435 protocol designer may double the range of possible values by 436 allowing negative integers -24 - -1. However, enumerating values 437 using negative integers may have unintended side-effects, because 438 some programming environments (e.g., C/C++) make implementation- 439 defined assumptions about the number of bits needed for an 440 enumerated type. 442 6.3. Factors Favoring UTF-8 String Enumerations 444 A protocol designer might choose UTF-8 strings for an enumerated item 445 in view of the following observations: 447 1. A specification can practically limit the content of UTF-8 448 strings to the ASCII range (or narrower), mitigating some 449 normalization problems. 451 2. UTF-8 strings are easier to read on-the-wire for humans. 453 3. UTF-8 strings can contain arbitrary textual identifiers, which 454 can be hierarchical, e.g., URIs. 456 6.4. OID Enumeration Example 458 An enumerated item indicates the revision level of a data format. 459 Revision levels are issued by year, such as 2011, 2012, etc. 460 However, in the year 2013, two revisions were issued: the first one 461 and an important update in June that needs to be distinguished. The 462 revision levels are assigned to some OID arc: 464 "{2 25 6464646464 revs(4)}" 466 In this arc, the following sub-arcs are assigned: 468 +--------------------+ 469 | Sub-Arc | 470 +--------------------+ 471 | {v2011(1)} | 472 | {v2012(2)} | 473 | {v2013(3)} | 474 | {v2013(3) june(6)} | 475 | {v2014(4)} | 476 | {v2015(5)} | 477 +--------------------+ 479 Table 2: Example Sub-Arcs 481 In CBOR, the enumeration is encoded as a relative OID. The schema 482 specifies the base OID arc, which is omitted: 484 c7 # tag(7) 485 41 03 # .3 487 c7 # tag(7) 488 42 0306 # .3.6 490 Figure 7: Enumerated Items in CBOR 492 .3 493 .{v2013(3) june(6)} 495 Figure 8: Enumerated Items in CBOR Diagnostic Notation 497 ".3" 498 ".3.6" 500 Figure 9: Enumerated Items in JSON (possibility 1) 502 "v2013" 503 "v2013/june" 505 Figure 10: Enumerated Items in JSON (possibility 2) 507 7. Tag Factoring and Tag Stacking with OID Arrays and Maps 509 A common use of OIDs in ASN.1 is to identify the kind of data in an 510 open type (Clause 3.8.57 of [X.680]), using information object 511 classes [X.681]. CBOR is schema-neutral, and (although not fully 512 discussed in [RFC7049]) semantic tagging was originally intended to 513 identify items in a global, context-free way (i.e., where a 514 specification would not repurpose a tag with different semantics than 515 its IANA registration). Therefore, using OIDs to identify contextual 516 data in a similar fashion to [X.681] is RECOMMENDED. 518 7.1. Tag Factoring 520 <> and <> can tag CBOR arrays and maps. The idea is that the 521 tag is factored out from each individual byte string; the tag is 522 placed in front of the array or map instead. The tags <> and 523 <> are left-distributive. 525 When the <> or <> tag is applied to an array, it means that the 526 respective tag is imputed to all items in the array. For example, 527 when the array is tagged with <>, every array item that is a 528 binary string is an OID. 530 When the <> or <> tag is applied to a map, it means that the 531 respective tag is imputed to all keys in the map. The values in the 532 map are not considered specially tagged. 534 Array and map stacking is permitted. For example, a 3-dimensional 535 array of OIDs can be composed by using a single <> tag, followed 536 by an array of arrays of arrays of binary strings. All such binary 537 strings are considered OIDs. 539 7.2. Switching OID and Relative OID 541 If an individual item in a <> or <> tagged array, or an 542 individual key in a <> or <> tagged map, is tagged with the 543 opposite tag (<> or <>) of the array or map itself, that tag 544 cancels and replaces the outer tag for that item. Like tags MUST NOT 545 be used on such individual items; such tagging is a coding error. 546 For example, if <> is the outer tag on an array and <> is the 547 inner tag on a binary string, semantically the inner item is treated 548 as a regular OID, not as a relative OID. 550 The purpose is to create more compact and flexible identifier spaces, 551 especially when object identifiers are used as enumerated items. 552 Examples: 554 <> outside, <> inside: An implementation that strives for a 555 compact representation, does not have to emit base OID arcs 556 repeatedly for each item. At the same time, if a private 557 organization or standards body separate from the specification needs 558 to identify something that the specification maintainers disagree 559 with, the separate body does not need to request registration of an 560 identifier under a controlled arc (i.e., the base arc of the relative 561 OIDs). 563 <> outside, <> inside: A collection of OIDs is supposed to be 564 open to all-comers, but a certain set of OIDs issued under a 565 particular arc is foreseeable for the majority of implementations. 566 For example, an OID protocol slot may identify cryptographic 567 algorithms: anyone can write (and has written) an algorithm with an 568 arbitrary OID. However, the protocol slot designer may wish to 569 privilege certain algorithms (and therefore OIDs) that are well-known 570 in that field of use. 572 7.3. Tag Stacking 574 CBOR permits tag stacking (tagging a tagged item), although this 575 technique has not been used much yet. This specification anticipates 576 that OIDs and relative OIDs will be associated with values with 577 uniform semantics. This section provides specific semantics when 578 tags are "stacked", that is, a CBOR item starts with tag <> or 579 <>, followed by one or more arbitrary tags ("subsequent tags"), 580 followed by a map or array. 582 7.3.1. Map 584 The overall gist is that the first tag applies to the keys in a map; 585 the subsequent tags apply to the values in a map. 587 When <> or <> is the first tag in a stack of tags, followed by 588 a map: 590 o The <> or <> tag indicates that the keys of the map are byte 591 string OIDs, byte string relative OIDs, or tag-factored arrays or 592 maps of the same. 594 o The subsequent tags uniformly apply to all of the values. 596 For example, if tag 32 (URL) is the subsequent tag, then all values 597 in the map are treated semantically as if tag 32 is applied to them 598 individually. See Figure 11. 600 It is possible that individual values can be tagged. Semantically, 601 these tags cumulate with the outer subsequent tags; inner value tags 602 do not cancel or replace the outer tags. 604 7.3.2. Array 606 The overall gist is that the first tag applies to the ordered "keys" 607 in the array (even-numbered items, assuming that the index starts at 608 0); the subsequent tags apply to the ordered "values" in the array 609 (odd-numbered items). This tagging technique creates an ordered 610 associative array. [[NB: Some call this the FORTRAN approach. need 611 to cite]] 613 When <> or <> is the first tag in a stack of tags, followed by 614 an array: 616 o The <> or <> tag indicates that alternating items, starting 617 with the first item, are byte string OIDs, byte string relative 618 OIDs, or tag-factored arrays or maps of the same. 620 o The subsequent tags uniformly apply to the alternating items, 621 starting with the second item. 623 o The array MUST have an even number of items; an array that has an 624 odd number of items is a coding error. 626 To create an ordered associative array wherein the values (even 627 elements) are arbitrarily tagged, stack tag 55799, self-describe CBOR 628 (Section 2.4.5 of [RFC7049]), after the <> or <> tag. Tag 629 55799 imparts no special semantics, so it is an effective 630 placeholder. (This sequence is mainly provided for completeness: it 631 is a more compact alternative to an array of duple-arrays that each 632 contain an OID or relative OID, and an arbitrary value.) 634 7.4. Diagnostic Notation for OID Arrays and Maps 636 There are no syntactic changes to diagnostic notation beyond 637 Section 5. Using <> or <> with arrays and maps, however, leads 638 to some sublime results. 640 When an array or map is tagged, that item is embraced with the usual 641 tag format: "<>()" or "<>()". This syntax 642 indicates the presence of the tag on the outer item. Inner items in 643 the array or keys in the map are noted in Section 5 form, but are not 644 individually tagged on-the-wire when the tag is the same as the outer 645 tag, because like-tagging is a coding error. 647 An array or map that involves a stack of tags is notated the usual 648 way. For example, the CBOR diagnostic notation of a map of OIDs to 649 URIs is: 651 6(32({0.9.2342.7776.1: "http://example.com/", 652 0.9.2342.7776.2: "ftp://ftp.example.com/pub/"})) 654 Figure 11: Map of OIDs to URIs, in CBOR Diagnostic Diagnostic 655 Notation 657 8. Applications and Examples of OIDs 659 8.1. GPU Farm 661 Consider a 3-dimensional OID array, indicating certain operations to 662 perform on a matrix of values in a GPU farm. Default operations are 663 under the OID arc 0.9.2342.7777 (such as .1, .2, .124, etc.); the arc 664 0.9.2342.7777 itself represents the identity operation. Certain 665 cryptographic operations like SHA-256 hashing 666 (2.16.840.1.101.3.4.2.1) are also permitted. The resulting notation 667 would be: 669 7([[[.1, .2, .3], 670 [.1, .2, .3], 671 [.1, .2, .3]], 672 [[.124, .125, .126], 673 [.95, .96, .97 ], 674 [.11, .12, .13 ]], 675 [[h'', .6, .4.2], 676 [.6, h'', .4.2], 677 [.6, 2.16.840.1.101.3.4.2.1, h'']]]) 679 Figure 12: GPU Farm Matrix Operations, in CBOR Diagnostic Notation 681 c7 # tag(7) 682 83 # array(3) 683 83 # array(3) 684 83 # array(3) 685 41 01 # .1 (2) 686 41 02 # .2 (2) 687 41 03 # .3 (2) 688 83 # array(3) 689 41 01 # .1 (2) 690 41 02 # .2 (2) 691 41 03 # .3 (2) 692 83 # array(3) 693 41 01 # .1 (2) 694 41 02 # .2 (2) 695 41 03 # .3 (2) 696 83 # array(3) 697 83 # array(3) 698 41 7c # .124 (2) 699 41 7d # .125 (2) 700 41 7e # .126 (2) 701 83 # array(3) 702 41 5f # .95 (2) 703 41 60 # .96 (2) 704 41 61 # .97 (2) 705 83 # array(3) 706 41 0b # .11 (2) 707 41 0c # .12 (2) 708 41 0d # .13 (2) 709 83 # array(3) 710 83 # array(3) 711 40 # (empty) (1) 712 41 06 # .6 (2) 713 42 0402 # .4.2 (3) 714 83 # array(3) 715 41 06 # .6 (2) 716 40 # (empty) (1) 717 42 0402 # .4.2 (3) 718 83 # array(3) 719 41 06 # .6 (2) 720 c6 49 608648016503040201 # 2.16.840.1.101.3.4.2.1 (10) 721 40 # (empty) (1) 723 Figure 13: GPU Farm Matrix Operations, in CBOR (76 bytes) 725 8.2. X.500 Distinguished Name 727 Consider the X.500 distinguished name: 729 +----------------------------------------------+--------------------+ 730 | Attribute Types | Attribute Values | 731 +----------------------------------------------+--------------------+ 732 | c (2.5.4.6) | US | 733 +----------------------------------------------+--------------------+ 734 | l (2.5.4.7) | Los Angeles | 735 | s (2.5.4.8) | CA | 736 | postalCode (2.5.4.17) | 90013 | 737 +----------------------------------------------+--------------------+ 738 | street (2.5.4.9) | 532 S Olive St | 739 +----------------------------------------------+--------------------+ 740 | businessCategory (2.5.4.15) | Public Park | 741 | buildingName (0.9.2342.19200300.100.1.48) | Pershing Square | 742 +----------------------------------------------+--------------------+ 744 Table 3: Example X.500 Distinguished Name 746 Table 3 has four RDNs. The country and street RDNs are single- 747 valued. The second and fourth RDNs are multi-valued. 749 The equivalent representations in CBOR diagnostic notation and CBOR 750 are: 752 6([{ 2.5.4.6: "US" }, 753 { 2.5.4.7: "Los Angeles", 2.5.4.8: "CA", 2.5.4.17: "90013" }, 754 { 2.5.4.9: "532 S Olive St" }, 755 { 2.5.4.15: "Public Park", 756 0.9.2342.19200300.100.1.48: "Pershing Square" }]) 758 Figure 14: Distinguished Name, in CBOR Diagnostic Notation 760 6([{ h'550406': "US" }, 761 { h'550407': "Los Angeles", h'550408': "CA", h'550411': "90013" }, 762 { h'550409': "532 S Olive St" }, 763 { h'55040f': "Public Park", 764 h'0992268993f22c640130': "Pershing Square" }]) 766 Figure 15: Distinguished Name, in CBOR Diagnostic Notation (RFC 7049 767 only) 769 c6 # tag(6) 770 84 # array(4) 771 a1 # map(1) 772 43 550406 # 2.5.4.6 (4) 773 62 # text(2) 774 5553 # "US" 775 a3 # map(3) 776 43 550407 # 2.5.4.7 (4) 777 6b # text(11) 778 4c6f7320416e67656c6573 # "Los Angeles" 779 43 550408 # 2.5.4.8 (4) 780 62 # text(2) 781 4341 # "CA" 782 43 550411 # 2.5.4.17 (4) 783 65 # text(5) 784 3930303133 # "90013" 785 a1 # map(1) 786 43 550409 # 2.5.4.9 (4) 787 6e # text(14) 788 3533322053204f6c697665205374 # "532 S Olive St" 789 a2 # map(2) 790 43 55040f # 2.5.4.15 (4) 791 6b # text(11) 792 5075626c6963205061726b # "Public Park" 793 4a 0992268993f22c640130 # 0.9.2342.19200300.100.1.48 (11) 794 6f # text(15) 795 5065727368696e6720537175617265 # "Pershing Square" 797 Figure 16: Distinguished Name, in CBOR (108 bytes) 799 (This example encoding assumes that all attribute values are UTF-8 800 strings, or can be represented as UTF-8 strings with no loss of 801 information.) 803 For reference, the [RFC4514] LDAP string encoding of such data would 804 be: 806 buildingName=Pershing Square+businessCategory=Public Park, 807 street=532 S Olive St,l=Los Angeles+postalCode=90013+st=CA,c=US 809 Figure 17: Distinguished Name, in LDAP String Encoding (121 bytes) 811 9. Binary Internet Messages and MIME Entities 813 Section 2.4.4.3 of [RFC7049] assigns tag 36 to "MIME messages 814 (including all headers)" [RFC2045], and prescribes UTF-8 strings, 815 without further elaboration. Actually MIME encircles several 816 different formats, and is not limited to UTF-8 strings. This section 817 updates tag 36. 819 9.1. CBOR Byte String and Binary MIME 821 Tag 36 is to be used with byte strings. When the tagged item is a 822 byte string, any octet can be used in the content. Arbitrary octets 823 are supported by [RFC2045] and can be supported in protocols such as 824 SMTP using BINARYMIME [RFC3030]. 826 A conforming implementation that purports to process tag 36-tagged 827 items, MUST accept byte strings as well as UTF-8 strings. Byte 828 strings, rather than UTF-8 strings, SHOULD be considered the default. 829 (While binary Content-Transfer-Encoding is not particularly common as 830 of this writing, 8-bit encoding is, and it is foreseeable that many 831 8-bit encoded messages will still have charsets other than UTF-8.) 833 9.2. Internet Messages, MIME Messages, and MIME Entities 835 Definitions: "MIME message" is not explicitly defined in [RFC2045], 836 but a careful read suggests that a MIME message is: "either a 837 (complete or "top-level") RFC 822 message being transferred on a 838 network, or a message encapsulated in a body of type "message/rfc822" 839 or "message/partial"," that also contains MIME header fields, namely, 840 MIME-Version field, which MUST be present (Section 4 of [RFC2045]. 841 Other MIME header fields such as Content-Type and Content-Transfer- 842 Encoding are assumed to be their [RFC2045] default values, if not 843 present in the data. 845 When the contents have a From field (a type of "originator address 846 field") and a Date field (the lone "origination date field") 847 (Section 3.6 of [RFC5322]), the item is concluded to have a Content- 848 Type of message/rfc822 or message/global, as appropriate, except as 849 otherwise specified in this section. 851 (TBD: Do we need a separate tag for a MIME entity?) (Alternate 852 proposal: When the tagged data does not include a MIME-Version field 853 or other fields required by RFC822 (5322) (e.g., no From field), it 854 is presumed to be a MIME entity, rather than a MIME message. 855 Therefore, it has no top-level content-type: instead it is simply a 856 "MIME entity", consisting of one element, whose Content-Type is the 857 content of the Content-Type header field, if present, or the 858 [RFC2045] default of "text/plain; charset=us-ascii", if absent. 859 Content-Transfer-Encoding SHALL be assumed to be 8bit when the CBOR 860 item is a UTF-8 string, and SHALL be assumed to be binary when the 861 CBOR item is a byte string. (Or should all be considered CTE: 862 binary?) And, when the tagged data has RFC822 required fields but no 863 MIME-Version, shall we assume it's a MIME entity, or shall we assume 864 it's an Internet message that does not conform to MIME?) 866 Content that has no headers whatsoever is valid, and implementations 867 that process tag 36 MUST permit this case: in such a case, the data 868 starts with CRLF CRLF, followed by the body. In such a case, the 869 content is assumed to be a MIME entity of Content-Type "text/plain; 870 charset=us-ascii", and not an RFC822 (RFC5322) Internet message. 871 (TBD: Confirm.) 873 9.3. Netnews, HTTP, and SIP Messages 875 Other message types that are MIME-related are message/news, message/ 876 http, and message/sip. 878 [RFC5537] specifies that message/news is deprecated (marked as 879 obsolete) and that message/rfc822 SHOULD be used in its place; 880 presumably this also extends to message/global over time. Netnews 881 Article Format [RFC5536] is a strict subset of Internet Message 882 Format; it can be detected by the presence of the six mandatory 883 header fields: Date, From, Message-ID, Newsgroups, Path, and Subject. 884 (Newsgroups and Path fields are specific to Netnews.) 886 message/http [RFC7230] is the media type for HTTP requests and 887 responses. It can be detected by analyzing the first line of the 888 body, which is an HTTP Start Line (Section 3.1 of [RFC7230]): it does 889 not conform to the syntax of an Internet Message Format header field. 890 The optional parameter "msgtype" can be inferred from the Start Line. 891 Implementers need to be aware that the default character encoding for 892 message/http is ISO-8859-1, not UTF-8. Therefore, implementations 893 SHOULD NOT encode HTTP messages with CBOR UTF-8 strings. 895 Similarly, message/sip [RFC3261] is the media type of SIP request and 896 response messages. It can be detected by analyzing the first line of 897 the body, which is a SIP start-line (Section 7.1 of [RFC3261]): it 898 does not conform to the syntax of an Internet Message Format header 899 field. The optional parameter can be inferred from the start-line. 901 9.4. Other Messages 903 The CBOR binary or UTF-8 string MAY contain other types of messages. 904 An implementation MAY send such a message as a MIME entity with the 905 Content-Type field appropriately set, or alternatively, MAY send the 906 message at the top-level directly. However, if a purported message 907 type is ambiguous with a message/rfc822 (or message/global) message, 908 a receiver SHALL treat the message as message/rfc822 (or message/ 909 global). If a purported message type is ambiguous with a MIME entity 910 (and unambiguously not message/rfc822 or message/global), a receiver 911 SHALL treat the message as a MIME entity. 913 10. Applications and Examples of Messages and Entities 915 Tag 36 is the RECOMMENDED way to convey data with MIME-related 916 metadata, including messages (which may or may not actually be MIME- 917 enabled) and MIME entities. 919 Example 1: A legacy RFC822 message is encoded as a UTF-8 string or 920 byte string with tag 36. The contents have From, To, Date, and 921 Subject header fields, two CRLFs, and a single line "Hello World!", 922 terminated with a CRLF. 924 Example 2a: A [RFC5280] certificate is encoded as a byte string with 925 tag 36. The contents are comprised of "Content-Type: application/ 926 pkix-cert", two CRLFs, and the DER encoding of the certificate. (The 927 "Content-Transfer-Encoding: binary" header is not necessary.) 929 Example 2b: A [RFC5280] certificate is encoded as a UTF-8 string or 930 byte string with tag 36. The contents are comprised of "Content- 931 Type: application/pkix-cert", a CRLF, "Content-Transfer-Encoding: 932 base64", two CRLFs, and the base64 encoding of the DER encoding of 933 the certificate, conforming to Section 6.8 of [RFC2045]. In 934 particular, base64 lines are limted to 76 characters, separated by 935 CRLF, and the final line is supposed to end with CRLF. Needless to 936 say, this is not nearly as efficient as Example 2a. 938 11. X.690 Series Tags 940 [[NB: Carsten probably won't like this. Plan on removing this 941 section. It is mainly provided to contrast with Section 10.]] 943 It is foreseeable that CBOR applications will need to send and 944 receive ASN.1 data, for example, for legacy or security applications. 945 While a native representation in CBOR is preferred, preserving the 946 data in an ASN.1 encoding may be necessary, for example, to preserve 947 cryptographic verification. A tag <> is allocated for this 948 purpose. 950 When the tagged item is a byte string, the byte string contents are 951 encoded according to [X.690], i.e., BER, CER, or DER. CBOR 952 implementations are not required to validate conformance of the 953 contained data to [X.690]. 955 When the tagged item is an array with 3 items: 957 1. The first item SHALL be an OID (with tag <> omitted; it SHALL 958 NOT be a relative OID), indicating the ASN.1 module containing 959 the type of the PDU. [[NB: this is a good example of a non- 960 trivial structure in which an element is well-defined to be an 961 OID, which has a tag. Is the CBOR philosophy to tag the item, or 962 omit the tag on the item, when the item's semantics are already 963 fixed by the outer tag? Similar situations can apply to tag 32 964 (URI), etc.]] 966 2. The second item SHALL be a UTF-8 string indicating the ASN.1 967 value's _type reference name_ (Clause 3.8.88 of [X.680]) 968 conforming to the "typereference" production (Clause 12.2 of 969 [X.680]). 971 3. The third item SHALL be a byte string, whose contents are encoded 972 per the prior paragraph. 974 (TBD: Use of tagged UTF-8 string is reserved for ASN.1 textual 975 formats such as XER and ASN.1 value notation? Probably not 976 necessary. Just omit.) 978 Implementation note: DER-encoded items are always definite-length, so 979 there is very little reason to use CBOR byte string indefinite 980 encoding when encoding such DER-encoded items. 982 Example: A [RFC5280] certificate can be encoded: 984 1. as a byte string with tag <>, or 986 2. as an array with tag <>, with three elements: 988 (1) a byte string "h'2B 06 01 05 05 07 00 12'", which is the BER 989 encoding of 1.3.6.1.5.5.7.0.18, 991 (2) a UTF-8 string "Certificate", and 993 (3) a byte string containing the DER encoding of the 994 certificate. 996 12. Regular Expression Clarification 998 (TODO: better specify conformance to actual regular expression 999 standards with tag 35. PCRE and JavaScript/ECMAScript regular 1000 expressions are very different; [RFC7049] is not specific enough 1001 about this.) 1003 13. Set and Multiset Technique 1005 CBOR has no native type for a set, which is an arbitrary unordered 1006 collection of items. The following technique is RECOMMENDED to 1007 express set and multiset semantics concisely in native CBOR data. 1009 In computer science, a _set_ is a collection of distinct items; there 1010 is no ordering to the items. Thus, implementations can optimize set 1011 storage in many ways that are not available with ordered elements in 1012 arrays. Sets can be stored in hashtables, bit fields, trees, or 1013 other abstract data types. 1015 In computer science, a _multiset_ allows multiple instances of a 1016 set's elements. Put another way, each distinct item has a 1017 cardinality property indicating the number of these items in the 1018 multiset. 1020 To store items in a set or multiset, it is RECOMMENDED to store the 1021 CBOR items as keys in a map; the values SHALL all be positive 1022 integers (major type 0, value/additional information greater than or 1023 equal to 1). In the special case of a set, the values SHALL be the 1024 integer 1. This technique has no special tag associated with it. As 1025 with arrays that schemas classify as "records" (i.e., arrays with 1026 positionally defined elements), schemas are likewise free to classify 1027 maps as sets in particular instances. 1029 14. Fruits Basket Example 1031 Consider a basket of fruits. The basket can contain any number of 1032 fruits; each fruit of the same species is considered identical. This 1033 basket has two apples, four bananas, six pears, and one pineapple: 1035 {"\u{1F34E}": 2, "\u{1F34C}": 4, 1036 "\u{1F350}": 6, "\u{1F34D}": 1} 1038 Figure 18: Fruits Basket in CBOR Diagnostic Notation 1040 A4 # map(4) 1041 64 # text(4) 1042 f09f8d8e # "\u{1F34E}" 1043 02 # unsigned(2) 1044 64 # text(4) 1045 f09f8d8c # "\u{1F34C}" 1046 04 # unsigned(4) 1047 64 # text(4) 1048 f09f8d90 # "\u{1F350}" 1049 06 # unsigned(6) 1050 64 # text(4) 1051 f09f8d8d # "\u{1F34D}" 1052 01 # unsigned(1) 1054 Figure 19: Fruits Basket in CBOR (33 bytes) 1056 [[TODO: Consider a Merkle Tree example: set of sets of sets of sets 1057 of things. ???]] 1059 15. IANA Considerations 1061 (This section to be edited by the RFC editor.) 1063 15.1. CBOR Tags 1065 IANA is requested to assign the CBOR tags in Table 4, with the 1066 present document as the specification reference. 1068 +----------+-------------+------------------------------------------+ 1069 | Tag | Data Item | Semantics | 1070 +----------+-------------+------------------------------------------+ 1071 | 6<> | byte string | ASN.1 object identifier (absolute, in | 1072 | | | BER encoding) | 1073 | 7<> | byte string | ASN.1 object identifier (relative, in | 1074 | | | BER encoding) | 1075 +----------+-------------+------------------------------------------+ 1077 Table 4: Values for Tags 1079 15.2. Discussion 1081 (This subsection to be removed by the RFC editor.) 1083 The space for single-byte tags in CBOR (0..23) is severely limited. 1084 It is not clear that the benefits of encoding OIDs/relative OIDs with 1085 one less byte per instance outweigh the consumption of two values in 1086 this code point space. 1088 Procedurally, this space is also reserved for standards action. 1090 An alternative would be to go for the specification required space, 1091 e.g. tag number 40 for <> and tag number 41 for <>. As an 1092 example this would change Figure 2 into: 1094 d8 28 # tag(40) 1095 49 # bytes(9) 1096 60 86 48 01 65 03 04 02 01 # 1098 Figure 20: SHA-256 OID in cbor (using specification required tag) 1100 15.3. Pre-Existing Tags 1102 (TODO: complete.) IANA is requested to modify the registrations for 1103 the following CBOR tags: 1105 Tag 36. 1107 15.4. New Tags 1109 (TODO: complete.) 1111 16. Security Considerations 1113 The security considerations of RFC 7049 apply. 1115 The encodings in Clauses 8.19 and 8.20 of [X.690] are extremely 1116 compact and unambiguous, but MUST be followed precisely to avoid 1117 security pitfalls. In particular, the requirements set out in 1118 Section 2.1 of this document need to be followed; otherwise, an 1119 attacker may be able to subvert a checking process by submitting 1120 alternative representations that are later taken as the original (or 1121 even something else entirely) by another decoder supposed to be 1122 protected by the checking process. 1124 OIDs and relative OIDs can always be treated as opaque byte strings. 1125 Actually understanding the structure that was used for generating 1126 them is not necessary, and, except for checking the structure 1127 requirements, it is strongly NOT RECOMMENDED to perform any 1128 processing of this kind (e.g., converting into dotted notation and 1129 back) unless absolutely necessary. If the OIDs are translated into 1130 other representations, the usual security considerations for non- 1131 trivial representation conversions apply; the integers of the sub- 1132 identifiers need to be handled as unlimited-range integers (cf. 1133 Figure 4). 1135 16.1. Conversions Between BER and Dotted Decimal Notation 1137 [PKILCAKE] uncovers exploit vectors for the illegal values above, as 1138 well as for cases in which conversion to or from the dotted decimal 1139 notation goes awry. Neither [X.660] nor [X.680] place an upper bound 1140 on the range of unsigned integer values for an arc; the integers are 1141 arbitrarily valued. An implementation SHOULD NOT attempt to convert 1142 each component using a fixed-size accumulator, as an attacker will 1143 certainly be able to cause the accumulator to overflow. Compact and 1144 efficient techniques for such conversions, such as the double dabble 1145 algorithm [DOUBLEDABBLE] are well-known in the art; their application 1146 to this field is left as an exercise to the reader. 1148 17. References 1150 17.1. Normative References 1152 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1153 Extensions (MIME) Part One: Format of Internet Message 1154 Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, 1155 . 1157 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1158 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 1159 RFC2119, March 1997, 1160 . 1162 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1163 A., Peterson, J., Sparks, R., Handley, M., and E. 1164 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1165 DOI 10.17487/RFC3261, June 2002, 1166 . 1168 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, DOI 1169 10.17487/RFC5322, October 2008, 1170 . 1172 [RFC5536] Murchison, K., Ed., Lindsey, C., and D. Kohn, "Netnews 1173 Article Format", RFC 5536, DOI 10.17487/RFC5536, November 1174 2009, . 1176 [RFC5537] Allbery, R., Ed. and C. Lindsey, "Netnews Architecture and 1177 Protocols", RFC 5537, DOI 10.17487/RFC5537, November 2009, 1178 . 1180 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 1181 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 1182 October 2013, . 1184 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1185 Protocol (HTTP/1.1): Message Syntax and Routing", RFC 1186 7230, DOI 10.17487/RFC7230, June 2014, 1187 . 1189 [X.660] International Telecommunications Union, "Information 1190 technology -- Procedures for the operation of object 1191 identifier registration authorities: General procedures 1192 and top arcs of the international object identifier tree", 1193 ITU-T Recommendation X.660, July 2011. 1195 [X.680] International Telecommunications Union, "Information 1196 technology -- Abstract Syntax Notation One (ASN.1): 1197 Specification of basic notation", ITU-T Recommendation 1198 X.680, August 2015. 1200 [X.690] International Telecommunications Union, "Information 1201 technology -- ASN.1 encoding rules: Specification of Basic 1202 Encoding Rules (BER), Canonical Encoding Rules (CER) and 1203 Distinguished Encoding Rules (DER)", ITU-T Recommendation 1204 X.690, August 2015. 1206 17.2. Informative References 1208 [CCITT.X208.1988] 1209 International Telephone and Telegraph Consultative 1210 Committee, "Specification of Abstract Syntax Notation One 1211 (ASN.1)", CCITT Recommendation X.208, November 1988. 1213 [DOUBLEDABBLE] 1214 Gao, S., Al-Khalili, D., and N. Chabini, "An improved BCD 1215 adder using 6-LUT FPGAs", IEEE 10th International New 1216 Circuits and Systems Conference (NEWCAS 2012), pp. 13-16, 1217 DOI: 10.1109/NEWCAS.2012.6328944, June 2012. 1219 [OID-INFO] 1220 Orange SA, "OID Repository", 2016, 1221 . 1223 [PKILCAKE] 1224 Kaminsky, D., Patterson, M., and L. Sassaman, "PKI Layer 1225 Cake: New Collision Attacks Against the Global X.509 1226 Infrastructure", FC 2010, Lecture Notes in Computer 1227 Science 6052 289-303, DOI: 10.1007/978-3-642-14577-3_22, 1228 January 2010, . 1230 [RFC3030] Vaudreuil, G., "SMTP Service Extensions for Transmission 1231 of Large and Binary MIME Messages", RFC 3030, DOI 1232 10.17487/RFC3030, December 2000, 1233 . 1235 [RFC4514] Zeilenga, K., Ed., "Lightweight Directory Access Protocol 1236 (LDAP): String Representation of Distinguished Names", RFC 1237 4514, DOI 10.17487/RFC4514, June 2006, 1238 . 1240 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1241 Housley, R., and W. Polk, "Internet X.509 Public Key 1242 Infrastructure Certificate and Certificate Revocation List 1243 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 1244 . 1246 [RFC6256] Eddy, W. and E. Davies, "Using Self-Delimiting Numeric 1247 Values in Protocols", RFC 6256, DOI 10.17487/RFC6256, May 1248 2011, . 1250 [RFC7388] Schoenwaelder, J., Sehgal, A., Tsou, T., and C. Zhou, 1251 "Definition of Managed Objects for IPv6 over Low-Power 1252 Wireless Personal Area Networks (6LoWPANs)", RFC 7388, DOI 1253 10.17487/RFC7388, October 2014, 1254 . 1256 [X.672] International Telecommunications Union, "Information 1257 technology -- Open systems interconnection -- Object 1258 identifier resolution system", ITU-T Recommendation X.672, 1259 August 2010. 1261 [X.681] International Telecommunications Union, "Information 1262 technology -- Abstract Syntax Notation One (ASN.1): 1263 Information object specification", ITU-T Recommendation 1264 X.681, August 2015. 1266 Appendix A. Changes from -02 to -03 1268 Many significant changes occurred in this version. These changes 1269 include: 1271 o Expanded the draft scope to be a comprehensive CBOR update. 1273 o Added OID-related sections: OID Enumerations, OID Maps and Arrays, 1274 and Applications and Examples of OIDs. 1276 o Added Tag 36 update (binary MIME, better definitions). 1278 o Added stub/experimental sections for X.690 Series Tags (tag <>) 1279 and Regular Expressions (tag 35). 1281 o Added technique for representing sets and multisets. 1283 o Added references and fixed typos. 1285 Authors' Addresses 1287 Carsten Bormann 1288 Universitaet Bremen TZI 1289 Postfach 330440 1290 Bremen D-28359 1291 Germany 1293 Phone: +49-421-218-63921 1294 Email: cabo@tzi.org 1296 Sean Leonard 1297 Penango, Inc. 1298 5900 Wilshire Boulevard 1299 21st Floor 1300 Los Angeles, CA 90036 1301 USA 1303 Email: dev+ietf@seantek.com 1304 URI: http://www.penango.com/