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