idnits 2.17.1 draft-bormann-cbor-tags-oid-02.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 1 instance 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 (January 06, 2016) is 3033 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) Summary: 1 error (**), 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: July 9, 2016 Penango, Inc. 6 January 06, 2016 8 Concise Binary Object Representation (CBOR) Tags for 9 ASN.1 Object Identifiers 10 draft-bormann-cbor-tags-oid-02 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. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on July 9, 2016. 41 Copyright Notice 43 Copyright (c) 2016 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. ASN.1 Object Identifiers . . . . . . . . . . . . . . . . . . 3 60 3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 6 62 5. Diagnostic Notation . . . . . . . . . . . . . . . . . . . . . 7 63 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 64 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 65 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 68 1. Introduction 70 The Concise Binary Object Representation (CBOR, [RFC7049]) provides 71 for the interchange of structured data without a requirement for a 72 pre-agreed schema. RFC 7049 defines a basic set of data types, as 73 well as a tagging mechanism that enables extending the set of data 74 types supported via an IANA registry. 76 Many IETF protocols carry ASN.1 object identifiers, originally 77 defined in 1988 [CCITT.X208.1988] and most recently in 2008 [X.680]. 78 The ASN.1 Basic Encoding Rules (BER, [X.690]) specify the binary 79 encodings of both ASN.1 object identifiers and relative object 80 identifiers. The contents of these encodings can be carried in a 81 CBOR byte string. 83 This document defines two CBOR tags that cover the two kinds of ASN.1 84 object identifiers encoded in this way. It is intended as the 85 reference document for the IANA registration of the tags so defined. 87 1.1. Terminology 89 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 90 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 91 "OPTIONAL" in this document are to be interpreted as described in RFC 92 2119 [RFC2119]. 94 The terminology of RFC 7049 applies; in particular the term "byte" is 95 used in its now customary sense as a synonym for "octet". 97 2. ASN.1 Object Identifiers 99 The International Object Identifier tree [X.660] is a hierarchically 100 managed space of identifiers, each of which is uniquely represented 101 as a sequence of unsigned integers ("sub-identifiers") [X.680]. 102 While these sequences can easily be represented in CBOR arrays of 103 unsigned integers, a more compact representation can often be 104 achieved by adopting the widely used representation of ASN.1 object 105 identifiers defined in BER; this representation may also be more 106 amenable to processing by other software making use of ASN.1 object 107 identifiers. 109 BER represents the sequence of unsigned integers by concatenating 110 self-delimiting [RFC6256] representations of each of the sub- 111 identifiers in sequence. 113 ASN.1 distinguishes absolute object identifiers (ASN.1 Type "OBJECT 114 IDENTIFIER"), which begin at a root arc ([X.660] Clause 3.5.21), from 115 relative object identifiers (ASN.1 Type "RELATIVE-OID"), which begin 116 relative to some object identifier known from context ([X.680] Clause 117 3.8.63). As a special optimization, BER combines the first two 118 integers in an absolute object identifier into one numeric identifier 119 by making use of the property of the hierarchy that the first arc has 120 only three integer values (0, 1, and 2), and the second arcs under 0 121 and 1 are limited to the integer values between 0 and 39. (The root 122 arc "joint-iso-itu-t(2)" has no such limitations on its second arc.) 123 If X and Y are the first two integers, the single integer actually 124 encoded is computed as: 126 X * 40 + Y 128 The inverse transformation (again making use of the known ranges of X 129 and Y) is applied when decoding the ASN.1 object identifier. 131 Since the semantics of absolute and relative object identifiers 132 differ, this specification defines two tags: 134 Tag <> (value TBD): tags a byte string as the ASN.1 BER encoding 135 of an absolute object identifier (simply "object identifier" or 136 "OID"). 138 Tag <> (value TBD): tags a byte string as the ASN.1 BER encoding 139 of a relative object identifier (also "relative OID"). 141 2.1. Requirements on the byte string being tagged 143 A byte string tagged by <> or <> MUST be a syntactically valid 144 BER representation of an ASN.1 object identifier. Specifically: 146 o its first byte, and any byte that follows a byte that has the most 147 significant bit unset, MUST NOT be 0x80 (this requirement excludes 148 expressing the sub-identifiers with anything but the shortest 149 form) 151 o its last byte MUST NOT have the most significant bit set (this 152 requirement excludes an incomplete final sub-identifier) 154 If either of these invalid conditions are encountered, they MUST be 155 treated as decoding errors. Comparing two OIDs or relative OIDs for 156 equality in a byte-for-byte fashion may not be safe before these 157 checks succeed on at least one of them (this includes the case where 158 one of them is a local constant); a process implementing an exclusion 159 list MUST check for decoding errors first. 161 [X.680] restricts RELATIVE-OID values to have at least one sub- 162 identifier (array element). This specification permits empty 163 relative object identifiers; they may still be excluded by 164 application semantics. 166 [RFC7049] permits byte strings to be indefinite-length, with chunks 167 divided at arbitrary byte boundaries. This contrasts with text 168 strings, where each chunk in an indefinite-length text string is 169 required be well-formed UTF-8 on its own: splitting the octets of a 170 UTF-8 character encoding between chunks is not allowed. 172 By analogy to this principle and to Clauses 8.9.1 and 8.20.1 of 173 [X.690], the byte strings carrying the OIDs and relative OIDs are 174 also to be treated as indivisible units: They MUST be encoded in 175 definite-length form; indefinite-length form is treated as an 176 encoding error (and the same considerations as above apply). (An 177 added convenience is that CBOR encodings can be searched through 178 efficiently for specific OIDs or relative OIDs, without initiating 179 the decoding process.) 181 3. Examples 183 In the following examples, we are using tag number 6 for <> and 184 tag number 7 for <>. See Section 6.1. 186 3.1. Encoding of the SHA-256 OID 188 ASN.1 Value Notation 189 { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 190 csor(3) nistalgorithm(4) hashalgs(2) sha256(1) } 192 Dotted Decimal Notation (also XML Value Notation) 193 2.16.840.1.101.3.4.2.1 195 06 # UNIVERSAL TAG 6 196 09 # 9 bytes, primitive 197 60 86 48 01 65 03 04 02 01 # X.690 Clause 8.19 198 # | 840 1 | 3 4 2 1 show component encoding 199 # 2.16 101 201 Figure 1: SHA-256 OID in BER 203 C6 # 0b110_00110: mt 6, tag 6 204 49 # 0b010_01001: mt 2, 9 bytes 205 60 86 48 01 65 03 04 02 01 # X.690 Clause 8.19 207 Figure 2: SHA-256 OID in CBOR 209 3.2. Encoding of a UUID OID 211 UUID 212 8b0d1a20-dcc5-11d9-bda9-0002a5d5c51b 214 ASN.1 Value Notation 215 { joint-iso-itu-t(2) uuid(25) 216 geomicaGPAS(184830721219540099336690027854602552603) } 218 Dotted Decimal Notation (also XML Value Notation) 219 2.25.184830721219540099336690027854602552603 221 06 # UNIVERSAL TAG 6 222 14 # 20 bytes, primitive 223 69 82 96 8D 8D 88 9B CC A8 C7 B3 BD D4 C0 80 AA AE D7 8A 1B 224 # | 184830721219540099336690027854602552603 225 # 2.25 227 Figure 3: UUID in an object identifier, in BER 229 C6 # 0b110_00110: mt 6, tag 6 230 54 # 0b010_10100: mt 2, 20 bytes 231 69 82 96 8D 8D 88 9B CC A8 C7 B3 BD D4 C0 80 AA AE D7 8A 1B 233 Figure 4: UUID in an object identifier, in CBOR 235 3.3. Encoding of a MIB Relative OID 237 Given some OID (e.g., "lowpanMib", assumed to be "1.3.6.1.2.1.226" 238 [RFC7388]), to which the following is added: 240 ASN.1 Value Notation (not suitable for diagnostic notation) 241 { lowpanObjects(1) lowpanStats(1) lowpanOutTransmits(29) } 243 Dotted Decimal Notation (diagnostic notation; see Section 5) 244 .1.1.29 246 0D # UNIVERSAL TAG 13 247 03 # 3 bytes, primitive 248 01 01 1D # X.690 Clause 8.20 249 # 1 1 29 show component encoding 251 Figure 5: MIB relative object identifier, in BER 253 C7 # 0b110_00110: mt 6, tag 7 254 43 # 0b010_01001: mt 2 (bstr), 3 bytes 255 01 01 1D # X.690 Clause 8.20 257 Figure 6: MIB relative object identifier, in CBOR 259 This relative OID saves seven bytes compared to the full OID 260 encoding. 262 4. Discussion 264 Staying close to the way ASN.1 object identifiers are encoded in 265 ASN.1 BER makes back-and-forth translation easy. As of today, ASN.1 266 object identifiers are either used in dotted decimal form or BER 267 form, so there is an advantage in not inventing a third form. Also, 268 expectations of the cost of encoding ASN.1 object identifiers are 269 based on BER; using a different encoding might not be aligned with 270 these expectations. If additional information about an OID is 271 desired, lookup services such as the OID Resolution Service (ORS, 272 [X.672]) and the OID Repository (oid-info.com, [OIDINFO]) are 273 available. 275 This specification allocates two numbers out of the single-byte tag 276 space. This use of code point space is justified by the wide use of 277 object identifiers in data interchange. For most common OIDs in use 278 (namely those whose contents encode to less than 24 bytes), the CBOR 279 encoding will match the efficiency of [X.690]. (This preliminary 280 conclusion is likely to generate some discussion, see Section 6.1.) 282 5. Diagnostic Notation 284 Implementers will likely want to see OIDs and relative OIDs in their 285 "natural forms" (as sequences of decimal unsigned integers) for 286 diagnostic purposes. Accordingly, this section defines additional 287 syntactic elements that can be used in conjunction with the 288 diagnostic notation described in Section 6 of [RFC7049]. 290 An object identifier may be written in ASN.1 value notation (with 291 enclosing braces and secondary identifiers), or in dotted decimal 292 notation with at least three arcs. Both examples are shown in 293 Section 3. The surrounding tag notation is optional. The ASN.1 294 value notation for OIDs does not overlap with JSON object notation 295 for CBOR maps, because at least two arcs are required for a valid 296 OID. 298 A relative object identifier may be written in dotted decimal 299 notation only, prefixed with a dot as shown in Section 3.3. The 300 surrounding tag notation is optional. ASN.1 value notation is not 301 suitable for the diagnostic notation of relative OIDs because 302 knowledge of the base OID cannot be determined from the encoding 303 alone; such knowledge requires a protocol on top of CBOR. 305 The notation in this section may be employed in addition to the basic 306 notation, which would be a tagged binary string. 308 +------------------------------+--------------+------------+ 309 | RFC 7049 diagnostic notation | 6(h'2b0601') | 7(h'0601') | 310 +------------------------------+--------------+------------+ 311 | Dotted decimal notation | 1.3.6.1 | .6.1 | 312 | ASN.1 value notation | {1 3 6 1} | -N/A- | 313 +------------------------------+--------------+------------+ 315 Table 1: Examples for extended diagnostic notation 317 6. IANA Considerations 319 (This section to be edited by the RFC editor.) 321 IANA is requested to assign the CBOR tags in Table 2, with the 322 present document as the specification reference. 324 +----------+-------------+------------------------------------------+ 325 | Tag | Data Item | Semantics | 326 +----------+-------------+------------------------------------------+ 327 | 6<> | byte string | ASN.1 object identifier (absolute, in | 328 | | | BER encoding) | 329 | 7<> | byte string | ASN.1 object identifier (relative, in | 330 | | | BER encoding) | 331 +----------+-------------+------------------------------------------+ 333 Table 2: Values for Tags 335 6.1. Discussion 337 (This subsection to be removed by the RFC editor.) 339 The space for single-byte tags in CBOR (0..23) is severely limited. 340 It is not clear that the benefits of encoding OIDs/relative OIDs with 341 one less byte per instance outweigh the consumption of two values in 342 this code point space. 344 Procedurally, this space is also reserved for standards action. 346 An alternative would be to go for the specification required space, 347 e.g. tag number 40 for <> and tag number 41 for <>. As an 348 example this would change Figure 2 into: 350 d8 28 # tag(40) 351 49 # bytes(9) 352 60 86 48 01 65 03 04 02 01 # 354 Figure 7: SHA-256 OID in cbor (using specification required tag) 356 7. Security Considerations 358 The security considerations of RFC 7049 apply. 360 The encodings in Clauses 8.19 and 8.20 of [X.690] are extremely 361 compact and unambiguous, but MUST be followed precisely to avoid 362 security pitfalls. In particular, the requirements set out in 363 Section 2.1 of this document need to be followed; otherwise, an 364 attacker may be able to subvert a checking process by submitting 365 alternative representations that are later taken as the original (or 366 even something else entirely) by another decoder supposed to be 367 protected by the checking process. 369 OIDs and relative OIDs can always be treated as opaque byte strings. 370 Actually understanding the structure that was used for generating 371 them is not necessary, and, except for checking the structure 372 requirements, it is strongly NOT RECOMMENDED to perform any 373 processing of this kind (e.g., converting into dotted notation and 374 back) unless absolutely necessary. If the OIDs are translated into 375 other representations, the usual security considerations for non- 376 trivial representation conversions apply; the integers of the sub- 377 identifiers need to be handled as unlimited-range integers (cf. 378 Figure 4). 380 7.1. Conversions Between BER and Dotted Decimal Notation 382 [PKILCAKE] uncovers exploit vectors for the illegal values above, as 383 well as for cases in which conversion to or from the dotted decimal 384 notation goes awry. Neither [X.660] nor [X.680] place an upper bound 385 on the range of unsigned integer values for an arc; the integers are 386 arbitrarily valued. An implementation SHOULD NOT attempt to convert 387 each component using a fixed-size accumulator, as an attacker will 388 certainly be able to cause the accumulator to overflow. Compact and 389 efficient techniques for such conversions, such as the double dabble 390 algorithm [DOUBLEDABBLE] are well-known in the art; their application 391 to this field is left as an exercise to the reader. 393 8. References 395 8.1. Normative References 397 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 398 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 399 RFC2119, March 1997, 400 . 402 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 403 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 404 October 2013, . 406 [X.660] International Telecommunications Union, "Information 407 technology -- Procedures for the operation of object 408 identifier registration authorities: General procedures 409 and top arcs of the international object identifier tree", 410 ITU-T Recommendation X.660, July 2011. 412 [X.680] International Telecommunications Union, "Information 413 technology -- Abstract Syntax Notation One (ASN.1): 414 Specification of basic notation", ITU-T Recommendation 415 X.680, November 2008. 417 [X.690] International Telecommunications Union, "Information 418 technology -- ASN.1 encoding rules: Specification of Basic 419 Encoding Rules (BER), Canonical Encoding Rules (CER) and 420 Distinguished Encoding Rules (DER)", ITU-T Recommendation 421 X.690, November 2008. 423 8.2. Informative References 425 [CCITT.X208.1988] 426 International Telephone and Telegraph Consultative 427 Committee, "Specification of Abstract Syntax Notation One 428 (ASN.1)", CCITT Recommendation X.208, November 1988. 430 [DOUBLEDABBLE] 431 Gao, S., Al-Khalili, D., and N. Chabini, "An improved BCD 432 adder using 6-LUT FPGAs", IEEE 10th International New 433 Circuits and Systems Conference (NEWCAS 2012), pp. 13-16, 434 DOI: 10.1109/NEWCAS.2012.6328944, June 2012. 436 [OIDINFO] Orange SA, "OID Repository", 2014, 437 . 439 [PKILCAKE] 440 Kaminsky, D., Patterson, M., and L. Sassaman, "PKI Layer 441 Cake: New Collision Attacks Against the Global X.509 442 Infrastructure", FC 2010, Lecture Notes in Computer 443 Science 6052 289-303, DOI: 10.1007/978-3-642-14577-3_22, 444 January 2010, . 446 [RFC6256] Eddy, W. and E. Davies, "Using Self-Delimiting Numeric 447 Values in Protocols", RFC 6256, DOI 10.17487/RFC6256, May 448 2011, . 450 [RFC7388] Schoenwaelder, J., Sehgal, A., Tsou, T., and C. Zhou, 451 "Definition of Managed Objects for IPv6 over Low-Power 452 Wireless Personal Area Networks (6LoWPANs)", RFC 7388, DOI 453 10.17487/RFC7388, October 2014, 454 . 456 [X.672] International Telecommunications Union, "Information 457 technology -- Open systems interconnection -- Object 458 identifier resolution system", ITU-T Recommendation X.672, 459 August 2010. 461 Authors' Addresses 463 Carsten Bormann 464 Universitaet Bremen TZI 465 Postfach 330440 466 Bremen D-28359 467 Germany 469 Phone: +49-421-218-63921 470 Email: cabo@tzi.org 472 Sean Leonard 473 Penango, Inc. 474 5900 Wilshire Boulevard 475 21st Floor 476 Los Angeles, CA 90036 477 USA 479 Email: dev+ietf@seantek.com 480 URI: http://www.penango.com/