idnits 2.17.1 draft-bormann-cbor-tags-oid-00.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. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 139: '...y <> or <> MUST be a syntactical...' RFC 2119 keyword, line 143: '...icant bit unset, MUST NOT be 0x80 (thi...' RFC 2119 keyword, line 147: '...o its last byte MUST NOT have the mos...' RFC 2119 keyword, line 150: '...nditions are encountered, they MUST be...' RFC 2119 keyword, line 155: '... list MUST check for decoding errors...' (4 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 27, 2014) is 3468 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: 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: April 30, 2015 Penango, Inc. 6 October 27, 2014 8 Concise Binary Object Representation (CBOR) Tags for 9 ASN.1 Object Identifiers 10 draft-bormann-cbor-tags-oid-00 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 April 30, 2015. 41 Copyright Notice 43 Copyright (c) 2014 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 . . . . . . . . . . . . . . . . . . 2 60 3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 6 62 5. Diagnostic Notation . . . . . . . . . . . . . . . . . . . . . 6 63 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 64 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 65 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 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]) specifies 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 terminology of RFC 7049 applies; in particular the term "byte" is 90 used in its now customary sense as a synonym for "octet". 92 2. ASN.1 Object Identifiers 94 The International Object Identifier tree [X.660] is a hierarchically 95 managed space of identifiers, each of which is uniquely represented 96 as a sequence of unsigned integers ("sub-identifiers") [X.680]. 98 While these sequences can easily be represented in CBOR arrays of 99 unsigned integers, a more compact representation can often be 100 achieved by adopting the widely used representation of ASN.1 object 101 identifiers defined in BER; this representation may also be more 102 amenable to processing by other software making use of ASN.1 object 103 identifiers. 105 BER represents the sequence of unsigned integers by concatenating 106 self-delimiting [RFC6256] representations of each of the sub- 107 identifier in sequence. 109 ASN.1 distinguishes absolute object identifiers (ASN.1 Type "OBJECT 110 IDENTIFIER"), which begin at a root arc ([X.660] Clause 3.5.21), from 111 relative object identifiers (ASN.1 Type "RELATIVE-OID"), which begin 112 relative to some object identifier known from context ([X.680] Clause 113 3.8.63). As a special optimization, BER combines the first two 114 integers in an absolute object identifier into one numeric identifier 115 by making use of the property of the hierarchy that the first arc has 116 only three integer values (0, 1, and 2), and the second arcs under 0 117 and 1 are limited to the integer values between 0 and 39. (The root 118 arc "joint-iso-itu-t(2)" has no such limitations on its second arc.) 119 If X and Y are the first two integers, the single integer actually 120 encoded is computed as: 122 X * 40 + Y 124 The inverse transformation (again making use of the known ranges of X 125 and Y) is applied when decoding the ASN.1 object identifier. 127 Since the semantics of absolute and relative object identifiers 128 differ, this specification defines two tags: 130 Tag <> (value TBD): tags a byte string as the ASN.1 BER encoding 131 of an absolute object identifier (simply "object identifier" or 132 "OID"). 134 Tag <> (value TBD): tags a byte string as the ASN.1 BER encoding 135 of a relative object identifier (also "relative OID"). 137 2.1. Requirements on the byte string being tagged 139 A byte string tagged by <> or <> MUST be a syntactically valid 140 BER representation of an ASN.1 object identifier. Specifically: 142 o its first byte, and any byte that follows a byte that has the most 143 significant bit unset, MUST NOT be 0x80 (this requirement excludes 144 expressing the sub-identifiers with anything but the shortest 145 form) 147 o its last byte MUST NOT have the most significant bit set (this 148 requirement excludes an incomplete final sub-identifier) 150 If either of these invalid conditions are encountered, they MUST be 151 treated as decoding errors. Comparing two OIDs or relative OIDs for 152 equality in a byte-for-byte fashion may not be safe before these 153 checks succeed on at least one of them (this includes the case where 154 one of them is a local constant); a process implementing an exclusion 155 list MUST check for decoding errors first. 157 [X.680] restricts RELATIVE-OID values to have at least one sub- 158 identifier (array element). This specification permits empty 159 relative object identifiers; they may still be excluded by 160 application semantics. 162 [RFC7049] permits byte strings to be indefinite-length, with chunks 163 divided at arbitrary byte boundaries. This contrasts with text 164 strings, where each chunk in an indefinite-length text string is 165 required be well-formed UTF-8 on its own: splitting the octets of a 166 UTF-8 character encoding between chunks is not allowed. 168 By analogy to this principle and to Clauses 8.9.1 and 8.20.1 of 169 [X.690], the byte strings carrying the OIDs and relative OIDs are 170 also to be treated as indivisible units: They MUST be encoded in 171 definite-length form; indefinite-length form is treated as an 172 encoding error (and the same considerations as above apply). (An 173 added convenience is that CBOR encodings can be searched through 174 efficiently for specific OIDs or relative OIDs, without initiating 175 the decoding process.) 177 3. Examples 179 In the following examples, we are using tag number 6 for <> and 180 tag number 7 for <>. See Section 6.1. 182 3.1. Encoding of the SHA-256 OID 184 ASN.1 Value Notation 185 { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 186 csor(3) nistalgorithm(4) hashalgs(2) sha256(1) } 188 Dotted Decimal Notation (also XML Value Notation) 189 2.16.840.1.101.3.4.2.1 190 06 # UNIVERSAL TAG 6 191 09 # 9 bytes, primitive 192 60 86 48 01 65 03 04 02 01 # X.690 Clause 8.19 193 # | 840 1 | 3 4 2 1 show component encoding 194 # 2.16 101 196 Figure 1: SHA-256 OID in BER 198 C6 # 0b110_00110: mt 6, tag 6 199 49 # 0b010_01001: mt 2, 9 bytes 200 60 86 48 01 65 03 04 02 01 # X.690 Clause 8.19 202 Figure 2: SHA-256 OID in CBOR 204 3.2. Encoding of a UUID OID 206 UUID 207 8b0d1a20-dcc5-11d9-bda9-0002a5d5c51b 209 ASN.1 Value Notation 210 { joint-iso-itu-t(2) uuid(25) 211 geomicaGPAS(2957291539512641589387040445673640841648) } 213 Dotted Decimal Notation (also XML Value Notation) 214 2.25.2957291539512641589387040445673640841648 216 06 # UNIVERSAL TAG 6 217 14 # 20 bytes, primitive 218 69 A2 E1 D1 D1 83 B9 C5 88 F6 B7 DA C8 80 85 A5 EA F1 A3 30 219 # | 2957291539512641589387040445673640841648 220 # 2.25 222 Figure 3: UUID in an object identifier, in BER 224 C6 # 0b110_00110: mt 6, tag 6 225 54 # 0b010_10100: mt 2, 20 bytes 226 69 A2 E1 D1 D1 83 B9 C5 88 F6 B7 DA C8 80 85 A5 EA F1 A3 30` 228 Figure 4: UUID in an object identifier, in CBOR 230 3.3. Encoding of a MIB Relative OID 232 Given some OID (e.g., "lowpanMib", assumed to be "1.3.6.1.2.1.7001"), 233 to which the following is added: 235 ASN.1 Value Notation (not suitable for diagnostic notation) 236 { lowpanObjects(1) lowpanStats(1) lowpanOutTransmits(29) } 237 Dotted Decimal Notation (diagnostic notation; see Section 5) 238 .1.1.29 240 0D # UNIVERSAL TAG 13 241 03 # 3 bytes, primitive 242 01 01 1D # X.690 Clause 8.20 243 # 1 1 29 show component encoding 245 Figure 5: MIB relative object identifier, in BER 247 C7 # 0b110_00110: mt 6, tag 7 248 43 # 0b010_01001: mt 2 (bstr), 3 bytes 249 01 01 1D # X.690 Clause 8.20 251 Figure 6: MIB relative object identifier, in CBOR 253 This relative OID saves seven bytes compared to the full OID 254 encoding. 256 4. Discussion 258 Staying close to the way ASN.1 object identifiers are encoded in 259 ASN.1 BER makes back-and-forth translation easy. As of today, ASN.1 260 object identifiers are either used in dotted decimal form or BER 261 form, so there is an advantage in not inventing a third form. Also, 262 expectations of the cost of encoding ASN.1 object identifiers are 263 based on BER; using a different encoding might not be aligned with 264 these expectations. If additional information about an OID is 265 desired, lookup services such as the OID Resolution Service (ORS, 266 [X.672]) and the OID Repository (oid-info.com, [OIDINFO]) are 267 available. 269 This specification allocates two numbers out of the single-byte tag 270 space. This use of code point space is justified by the wide use of 271 object identifiers in data interchange. For most common OIDs in use 272 (namely those whose contents encode to less than 24 bytes), the CBOR 273 encoding will match the efficiency of [X.690]. 275 5. Diagnostic Notation 277 Implementers will likely want to see OIDs and relative OIDs in their 278 "natural forms" (as sequences of unsigned integers) for diagnostic 279 purposes. Accordingly, this section defines additional syntactic 280 elements that can be used in conjunction with the diagnostic notation 281 described in Section 6 of [RFC7049]. 283 An object identifier may be written in ASN.1 value notation (with 284 enclosing braces and secondary identifiers), or in dotted decimal 285 notation with at least three arcs. Both examples are shown in 286 Section 3. The surrounding tag notation is optional. The ASN.1 287 value notation for OIDs does not overlap with JSON object notation 288 for CBOR maps, because at least two arcs are required for a valid 289 OID. 291 A relative object identifier may be written in dotted decimal 292 notation only, prefixed with a dot as shown in Section 3.3. The 293 surrounding tag notation is optional. ASN.1 value notation is not 294 suitable for the diagnostic notation of relative OIDs because 295 knowledge of the base OID cannot be determined from the encoding 296 alone; such knowledge requires a protocol on top of CBOR. 298 The notation in this section may be employed in addition to the basic 299 notation, which would be a tagged binary string. 301 +------------------------------+----------------+------------+ 302 | RFC 7049 diagnostic notation | 6(h'2b030601') | 7(h'0601') | 303 +------------------------------+----------------+------------+ 304 | Dotted decimal notation | 1.3.6.1 | .6.1 | 305 | ASN.1 value notation | {1 3 6 1} | -N/A- | 306 +------------------------------+----------------+------------+ 308 Table 1: Examples for extended diagnostic notation 310 6. IANA Considerations 312 (This section to be edited by the RFC editor.) 314 IANA is requested to assign the CBOR tags in Table 2, with the 315 present document as the specification reference. 317 +----------+------------+-------------------------------------------+ 318 | Tag | Data Item | Semantics | 319 +----------+------------+-------------------------------------------+ 320 | 6<> | byte | ASN.1 object identifier (absolute, in BER | 321 | | string | encoding) | 322 | 7<> | byte | ASN.1 object identifier (relative, in BER | 323 | | string | encoding) | 324 +----------+------------+-------------------------------------------+ 326 Table 2: Values for Tags 328 6.1. Discussion 330 (This subsection to be removed by the RFC editor.) 331 The space for single-byte tags in CBOR (0..23) is severely limited. 332 It is not clear that the benefits of encoding OIDs/relative OIDs with 333 one less byte per instance outweigh the consumption of two values in 334 this code point space. 336 Procedurally, this space is also reserved for standards action. 338 An alternative would be to go for the specification required space, 339 e.g. tag number 40 for <> and tag number 41 for <>. As an 340 example this would change Figure 2 into: 342 d8 28 # tag(40) 343 49 # bytes(9) 344 60 86 48 01 65 03 04 02 01 # 346 Figure 7: SHA-256 OID in cbor (using specification required tag) 348 7. Security Considerations 350 The security considerations of RFC 7049 apply. 352 The encodings in Clauses 8.19 and 8.20 of [X.690] are extremely 353 compact and unambiguous, but MUST be followed precisely to avoid 354 security pitfalls. In particular, the requirements set out in 355 Section 2.1 of this document need to be followed; otherwise, an 356 attacker may be able to subvert a checking process by submitting 357 alternative representations that are later taken as the original (or 358 even something else entirely) by another decoder supposed to be 359 protected by the checking process. 361 OIDs and relative OIDs can always be treated as opaque byte strings. 362 Actually understanding the structure that was used for generating 363 them is not necessary, and, except for checking the structure 364 requirements, it is strongly NOT RECOMMENDED to perform any 365 processing of this kind (e.g., converting into dotted notation and 366 back) unless absolutely necessary. If the OIDs are translated into 367 other representations, the usual security considerations for non- 368 trivial representation conversions apply; the integers of the sub- 369 identifiers need to be handled as unlimited-range integers (cf. 370 Figure 4). 372 7.1. Conversions Between BER and Dotted Decimal Notation 374 [PKILCAKE] uncovers exploit vectors for the illegal values above, as 375 well as for cases in which conversion to or from the dotted decimal 376 notation goes awry. Neither [X.660] nor [X.680] place an upper bound 377 on the range of unsigned integer values for an arc; the integers are 378 arbitrarily valued. An implementation SHOULD NOT attempt to convert 379 each component using a fixed-size accumulator, as an attacker will 380 certainly be able to cause the accumulator to overflow. Compact and 381 efficient techniques for such conversions, such as the double dabble 382 algorithm [[TODO: CITE]], are well-known in the art; their 383 application to this field is left as an exercise to the reader. 385 8. References 387 8.1. Normative References 389 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 390 Representation (CBOR)", RFC 7049, October 2013. 392 [X.660] International Telecommunications Union, "Information 393 technology -- Procedures for the operation of object 394 identifier registration authorities: General procedures 395 and top arcs of the international object identifier tree", 396 ITU-T Recommendation X.660, July 2011. 398 [X.680] International Telecommunications Union, "Information 399 technology -- Abstract Syntax Notation One (ASN.1): 400 Specification of basic notation", ITU-T Recommendation 401 X.680, November 2008. 403 [X.690] International Telecommunications Union, "Information 404 technology -- ASN.1 encoding rules: Specification of Basic 405 Encoding Rules (BER), Canonical Encoding Rules (CER) and 406 Distinguished Encoding Rules (DER)", ITU-T Recommendation 407 X.690, November 2008. 409 8.2. Informative References 411 [CCITT.X208.1988] 412 International Telephone and Telegraph Consultative 413 Committee, "Specification of Abstract Syntax Notation One 414 (ASN.1)", CCITT Recommendation X.208, November 1988. 416 [OIDINFO] Orange SA, "OID Repository", 2014, 417 . 419 [PKILCAKE] 420 Kaminsky, D., Patterson, M., and L. Sassaman, "PKI Layer 421 Cake: New Collision Attacks Against the Global X.509 422 Infrastructure", FC 2010, Lecture Notes in Computer 423 Science 6052 289-303, January 2010, 424 . 426 doi:10.1007/978-3-642-14577-3_22 428 [RFC6256] Eddy, W. and E. Davies, "Using Self-Delimiting Numeric 429 Values in Protocols", RFC 6256, May 2011. 431 [X.672] International Telecommunications Union, "Information 432 technology -- Open systems interconnection -- Object 433 identifier resolution system", ITU-T Recommendation X.672, 434 August 2010. 436 Authors' Addresses 438 Carsten Bormann 439 Universitaet Bremen TZI 440 Postfach 330440 441 Bremen D-28359 442 Germany 444 Phone: +49-421-218-63921 445 Email: cabo@tzi.org 447 Sean Leonard 448 Penango, Inc. 449 5900 Wilshire Boulevard 450 21st Floor 451 Los Angeles, CA 90036 452 USA 454 Email: dev+ietf@seantek.com 455 URI: http://www.penango.com/