[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 draft-ietf-cbor-tags-oid

Network Working Group                                         C. Bormann
Internet-Draft                                   Universitaet Bremen TZI
Intended status: Standards Track                              S. Leonard
Expires: January 7, 2016                                   Penango, Inc.
                                                           July 06, 2015


          Concise Binary Object Representation (CBOR) Tags for
                        ASN.1 Object Identifiers
                     draft-bormann-cbor-tags-oid-01

Abstract

   The Concise Binary Object Representation (CBOR, RFC 7049) is a data
   format whose design goals include the possibility of extremely small
   code size, fairly small message size, and extensibility without the
   need for version negotiation.

   The present document makes use of this extensibility to define CBOR
   tags <<O>> and <<R>> [values TBD] for ASN.1 object identifiers.  It
   is intended as the reference document for the IANA registration of
   the CBOR tags so defined.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on January 7, 2016.

Copyright Notice

   Copyright (c) 2015 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of



Bormann & Leonard        Expires January 7, 2016                [Page 1]


Internet-Draft          CBOR Tags for ASN.1 OIDs               July 2015


   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  ASN.1 Object Identifiers  . . . . . . . . . . . . . . . . . .   3
   3.  Examples  . . . . . . . . . . . . . . . . . . . . . . . . . .   4
   4.  Discussion  . . . . . . . . . . . . . . . . . . . . . . . . .   6
   5.  Diagnostic Notation . . . . . . . . . . . . . . . . . . . . .   7
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

1.  Introduction

   The Concise Binary Object Representation (CBOR, [RFC7049]) provides
   for the interchange of structured data without a requirement for a
   pre-agreed schema.  RFC 7049 defines a basic set of data types, as
   well as a tagging mechanism that enables extending the set of data
   types supported via an IANA registry.

   Many IETF protocols carry ASN.1 object identifiers, originally
   defined in 1988 [CCITT.X208.1988] and most recently in 2008 [X.680].
   The ASN.1 Basic Encoding Rules (BER, [X.690]) specifies the binary
   encodings of both ASN.1 object identifiers and relative object
   identifiers.  The contents of these encodings can be carried in a
   CBOR byte string.

   This document defines two CBOR tags that cover the two kinds of ASN.1
   object identifiers encoded in this way.  It is intended as the
   reference document for the IANA registration of the tags so defined.

1.1.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

   The terminology of RFC 7049 applies; in particular the term "byte" is
   used in its now customary sense as a synonym for "octet".





Bormann & Leonard        Expires January 7, 2016                [Page 2]


Internet-Draft          CBOR Tags for ASN.1 OIDs               July 2015


2.  ASN.1 Object Identifiers

   The International Object Identifier tree [X.660] is a hierarchically
   managed space of identifiers, each of which is uniquely represented
   as a sequence of unsigned integers ("sub-identifiers") [X.680].
   While these sequences can easily be represented in CBOR arrays of
   unsigned integers, a more compact representation can often be
   achieved by adopting the widely used representation of ASN.1 object
   identifiers defined in BER; this representation may also be more
   amenable to processing by other software making use of ASN.1 object
   identifiers.

   BER represents the sequence of unsigned integers by concatenating
   self-delimiting [RFC6256] representations of each of the sub-
   identifier in sequence.

   ASN.1 distinguishes absolute object identifiers (ASN.1 Type "OBJECT
   IDENTIFIER"), which begin at a root arc ([X.660] Clause 3.5.21), from
   relative object identifiers (ASN.1 Type "RELATIVE-OID"), which begin
   relative to some object identifier known from context ([X.680] Clause
   3.8.63).  As a special optimization, BER combines the first two
   integers in an absolute object identifier into one numeric identifier
   by making use of the property of the hierarchy that the first arc has
   only three integer values (0, 1, and 2), and the second arcs under 0
   and 1 are limited to the integer values between 0 and 39.  (The root
   arc "joint-iso-itu-t(2)" has no such limitations on its second arc.)
   If X and Y are the first two integers, the single integer actually
   encoded is computed as:

      X * 40 + Y

   The inverse transformation (again making use of the known ranges of X
   and Y) is applied when decoding the ASN.1 object identifier.

   Since the semantics of absolute and relative object identifiers
   differ, this specification defines two tags:

   Tag <<O>> (value TBD): tags a byte string as the ASN.1 BER encoding
   of an absolute object identifier (simply "object identifier" or
   "OID").

   Tag <<R>> (value TBD): tags a byte string as the ASN.1 BER encoding
   of a relative object identifier (also "relative OID").








Bormann & Leonard        Expires January 7, 2016                [Page 3]


Internet-Draft          CBOR Tags for ASN.1 OIDs               July 2015


2.1.  Requirements on the byte string being tagged

   A byte string tagged by <<O>> or <<R>> MUST be a syntactically valid
   BER representation of an ASN.1 object identifier.  Specifically:

   o  its first byte, and any byte that follows a byte that has the most
      significant bit unset, MUST NOT be 0x80 (this requirement excludes
      expressing the sub-identifiers with anything but the shortest
      form)

   o  its last byte MUST NOT have the most significant bit set (this
      requirement excludes an incomplete final sub-identifier)

   If either of these invalid conditions are encountered, they MUST be
   treated as decoding errors.  Comparing two OIDs or relative OIDs for
   equality in a byte-for-byte fashion may not be safe before these
   checks succeed on at least one of them (this includes the case where
   one of them is a local constant); a process implementing an exclusion
   list MUST check for decoding errors first.

   [X.680] restricts RELATIVE-OID values to have at least one sub-
   identifier (array element).  This specification permits empty
   relative object identifiers; they may still be excluded by
   application semantics.

   [RFC7049] permits byte strings to be indefinite-length, with chunks
   divided at arbitrary byte boundaries.  This contrasts with text
   strings, where each chunk in an indefinite-length text string is
   required be well-formed UTF-8 on its own: splitting the octets of a
   UTF-8 character encoding between chunks is not allowed.

   By analogy to this principle and to Clauses 8.9.1 and 8.20.1 of
   [X.690], the byte strings carrying the OIDs and relative OIDs are
   also to be treated as indivisible units: They MUST be encoded in
   definite-length form; indefinite-length form is treated as an
   encoding error (and the same considerations as above apply).  (An
   added convenience is that CBOR encodings can be searched through
   efficiently for specific OIDs or relative OIDs, without initiating
   the decoding process.)

3.  Examples

   In the following examples, we are using tag number 6 for <<O>> and
   tag number 7 for <<O>>.  See Section 6.1.







Bormann & Leonard        Expires January 7, 2016                [Page 4]


Internet-Draft          CBOR Tags for ASN.1 OIDs               July 2015


3.1.  Encoding of the SHA-256 OID

   ASN.1 Value Notation
   { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101)
   csor(3) nistalgorithm(4) hashalgs(2) sha256(1) }

   Dotted Decimal Notation (also XML Value Notation)
   2.16.840.1.101.3.4.2.1

   06                                # UNIVERSAL TAG 6
      09                             # 9 bytes, primitive
         60 86 48 01 65 03 04 02 01  # X.690 Clause 8.19
   #      |   840  1  |  3  4  2  1    show component encoding
   #   2.16         101

                       Figure 1: SHA-256 OID in BER

   C6                                # 0b110_00110: mt 6, tag 6
      49                             # 0b010_01001: mt 2, 9 bytes
         60 86 48 01 65 03 04 02 01  # X.690 Clause 8.19

                       Figure 2: SHA-256 OID in CBOR

3.2.  Encoding of a UUID OID

   UUID
   8b0d1a20-dcc5-11d9-bda9-0002a5d5c51b

   ASN.1 Value Notation
   { joint-iso-itu-t(2) uuid(25)
   geomicaGPAS(2957291539512641589387040445673640841648) }

   Dotted Decimal Notation (also XML Value Notation)
   2.25.2957291539512641589387040445673640841648

   06                                # UNIVERSAL TAG 6
      14                             # 20 bytes, primitive
         69 A2 E1 D1 D1 83 B9 C5 88 F6 B7 DA C8 80 85 A5 EA F1 A3 30
   #      |                 2957291539512641589387040445673640841648
   #   2.25

              Figure 3: UUID in an object identifier, in BER

   C6                                # 0b110_00110: mt 6, tag 6
      54                             # 0b010_10100: mt 2, 20 bytes
         69 A2 E1 D1 D1 83 B9 C5 88 F6 B7 DA C8 80 85 A5 EA F1 A3 30`

              Figure 4: UUID in an object identifier, in CBOR



Bormann & Leonard        Expires January 7, 2016                [Page 5]


Internet-Draft          CBOR Tags for ASN.1 OIDs               July 2015


3.3.  Encoding of a MIB Relative OID

   Given some OID (e.g., "lowpanMib", assumed to be "1.3.6.1.2.1.226"
   [RFC7388]), to which the following is added:

   ASN.1 Value Notation (not suitable for diagnostic notation)
   { lowpanObjects(1) lowpanStats(1) lowpanOutTransmits(29) }

   Dotted Decimal Notation (diagnostic notation; see Section 5)
   .1.1.29

   0D                                # UNIVERSAL TAG 13
      03                             # 3 bytes, primitive
         01 01 1D                    # X.690 Clause 8.20
   #      1  1 29                      show component encoding

             Figure 5: MIB relative object identifier, in BER

   C7                                # 0b110_00110: mt 6, tag 7
      43                             # 0b010_01001: mt 2 (bstr), 3 bytes
         01 01 1D                    # X.690 Clause 8.20

             Figure 6: MIB relative object identifier, in CBOR

   This relative OID saves seven bytes compared to the full OID
   encoding.

4.  Discussion

   Staying close to the way ASN.1 object identifiers are encoded in
   ASN.1 BER makes back-and-forth translation easy.  As of today, ASN.1
   object identifiers are either used in dotted decimal form or BER
   form, so there is an advantage in not inventing a third form.  Also,
   expectations of the cost of encoding ASN.1 object identifiers are
   based on BER; using a different encoding might not be aligned with
   these expectations.  If additional information about an OID is
   desired, lookup services such as the OID Resolution Service (ORS,
   [X.672]) and the OID Repository (oid-info.com, [OIDINFO]) are
   available.

   This specification allocates two numbers out of the single-byte tag
   space.  This use of code point space is justified by the wide use of
   object identifiers in data interchange.  For most common OIDs in use
   (namely those whose contents encode to less than 24 bytes), the CBOR
   encoding will match the efficiency of [X.690].






Bormann & Leonard        Expires January 7, 2016                [Page 6]


Internet-Draft          CBOR Tags for ASN.1 OIDs               July 2015


5.  Diagnostic Notation

   Implementers will likely want to see OIDs and relative OIDs in their
   "natural forms" (as sequences of unsigned integers) for diagnostic
   purposes.  Accordingly, this section defines additional syntactic
   elements that can be used in conjunction with the diagnostic notation
   described in Section 6 of [RFC7049].

   An object identifier may be written in ASN.1 value notation (with
   enclosing braces and secondary identifiers), or in dotted decimal
   notation with at least three arcs.  Both examples are shown in
   Section 3.  The surrounding tag notation is optional.  The ASN.1
   value notation for OIDs does not overlap with JSON object notation
   for CBOR maps, because at least two arcs are required for a valid
   OID.

   A relative object identifier may be written in dotted decimal
   notation only, prefixed with a dot as shown in Section 3.3.  The
   surrounding tag notation is optional.  ASN.1 value notation is not
   suitable for the diagnostic notation of relative OIDs because
   knowledge of the base OID cannot be determined from the encoding
   alone; such knowledge requires a protocol on top of CBOR.

   The notation in this section may be employed in addition to the basic
   notation, which would be a tagged binary string.

      +------------------------------+----------------+------------+
      | RFC 7049 diagnostic notation | 6(h'2b030601') | 7(h'0601') |
      +------------------------------+----------------+------------+
      | Dotted decimal notation      | 1.3.6.1        | .6.1       |
      | ASN.1 value notation         | {1 3 6 1}      | -N/A-      |
      +------------------------------+----------------+------------+

            Table 1: Examples for extended diagnostic notation

6.  IANA Considerations

   (This section to be edited by the RFC editor.)

   IANA is requested to assign the CBOR tags in Table 2, with the
   present document as the specification reference.










Bormann & Leonard        Expires January 7, 2016                [Page 7]


Internet-Draft          CBOR Tags for ASN.1 OIDs               July 2015


   +----------+-------------+------------------------------------------+
   | Tag      | Data Item   |                                Semantics |
   +----------+-------------+------------------------------------------+
   | 6<<TBD>> | byte string |    ASN.1 object identifier (absolute, in |
   |          |             |                            BER encoding) |
   | 7<<TBD>> | byte string |    ASN.1 object identifier (relative, in |
   |          |             |                            BER encoding) |
   +----------+-------------+------------------------------------------+

                         Table 2: Values for Tags

6.1.  Discussion

   (This subsection to be removed by the RFC editor.)

   The space for single-byte tags in CBOR (0..23) is severely limited.
   It is not clear that the benefits of encoding OIDs/relative OIDs with
   one less byte per instance outweigh the consumption of two values in
   this code point space.

   Procedurally, this space is also reserved for standards action.

   An alternative would be to go for the specification required space,
   e.g. tag number 40 for <<O>> and tag number 41 for <<R>>.  As an
   example this would change Figure 2 into:

   d8 28                            # tag(40)
      49                            # bytes(9)
         60 86 48 01 65 03 04 02 01 #

     Figure 7: SHA-256 OID in cbor (using specification required tag)

7.  Security Considerations

   The security considerations of RFC 7049 apply.

   The encodings in Clauses 8.19 and 8.20 of [X.690] are extremely
   compact and unambiguous, but MUST be followed precisely to avoid
   security pitfalls.  In particular, the requirements set out in
   Section 2.1 of this document need to be followed; otherwise, an
   attacker may be able to subvert a checking process by submitting
   alternative representations that are later taken as the original (or
   even something else entirely) by another decoder supposed to be
   protected by the checking process.

   OIDs and relative OIDs can always be treated as opaque byte strings.
   Actually understanding the structure that was used for generating
   them is not necessary, and, except for checking the structure



Bormann & Leonard        Expires January 7, 2016                [Page 8]


Internet-Draft          CBOR Tags for ASN.1 OIDs               July 2015


   requirements, it is strongly NOT RECOMMENDED to perform any
   processing of this kind (e.g., converting into dotted notation and
   back) unless absolutely necessary.  If the OIDs are translated into
   other representations, the usual security considerations for non-
   trivial representation conversions apply; the integers of the sub-
   identifiers need to be handled as unlimited-range integers (cf.
   Figure 4).

7.1.  Conversions Between BER and Dotted Decimal Notation

   [PKILCAKE] uncovers exploit vectors for the illegal values above, as
   well as for cases in which conversion to or from the dotted decimal
   notation goes awry.  Neither [X.660] nor [X.680] place an upper bound
   on the range of unsigned integer values for an arc; the integers are
   arbitrarily valued.  An implementation SHOULD NOT attempt to convert
   each component using a fixed-size accumulator, as an attacker will
   certainly be able to cause the accumulator to overflow.  Compact and
   efficient techniques for such conversions, such as the double dabble
   algorithm [DOUBLEDABBLE] are well-known in the art; their application
   to this field is left as an exercise to the reader.

8.  References

8.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC7049]  Bormann, C. and P. Hoffman, "Concise Binary Object
              Representation (CBOR)", RFC 7049, October 2013.

   [X.660]    International Telecommunications Union, "Information
              technology -- Procedures for the operation of object
              identifier registration authorities: General procedures
              and top arcs of the international object identifier tree",
              ITU-T Recommendation X.660, July 2011.

   [X.680]    International Telecommunications Union, "Information
              technology -- Abstract Syntax Notation One (ASN.1):
              Specification of basic notation", ITU-T Recommendation
              X.680, November 2008.

   [X.690]    International Telecommunications Union, "Information
              technology -- ASN.1 encoding rules: Specification of Basic
              Encoding Rules (BER), Canonical Encoding Rules (CER) and
              Distinguished Encoding Rules (DER)", ITU-T Recommendation
              X.690, November 2008.




Bormann & Leonard        Expires January 7, 2016                [Page 9]


Internet-Draft          CBOR Tags for ASN.1 OIDs               July 2015


8.2.  Informative References

   [CCITT.X208.1988]
              International Telephone and Telegraph Consultative
              Committee, "Specification of Abstract Syntax Notation One
              (ASN.1)", CCITT Recommendation X.208, November 1988.

   [DOUBLEDABBLE]
              Gao, S., Al-Khalili, D., and N. Chabini, "An improved BCD
              adder using 6-LUT FPGAs", IEEE 10th International New
              Circuits and Systems Conference (NEWCAS 2012), pp. 13-16,
              DOI: 10.1109/NEWCAS.2012.6328944, June 2012.

   [OIDINFO]  Orange SA, "OID Repository", 2014,
              <http://www.oid-info.com/>.

   [PKILCAKE]
              Kaminsky, D., Patterson, M., and L. Sassaman, "PKI Layer
              Cake: New Collision Attacks Against the Global X.509
              Infrastructure", FC 2010, Lecture Notes in Computer
              Science 6052 289-303, DOI: 10.1007/978-3-642-14577-3_22,
              January 2010, <http://dl.acm.org/citation.cfm?id=2163593>.

   [RFC6256]  Eddy, W. and E. Davies, "Using Self-Delimiting Numeric
              Values in Protocols", RFC 6256, May 2011.

   [RFC7388]  Schoenwaelder, J., Sehgal, A., Tsou, T., and C. Zhou,
              "Definition of Managed Objects for IPv6 over Low-Power
              Wireless Personal Area Networks (6LoWPANs)", RFC 7388,
              October 2014.

   [X.672]    International Telecommunications Union, "Information
              technology -- Open systems interconnection -- Object
              identifier resolution system", ITU-T Recommendation X.672,
              August 2010.

Authors' Addresses

   Carsten Bormann
   Universitaet Bremen TZI
   Postfach 330440
   Bremen  D-28359
   Germany

   Phone: +49-421-218-63921
   Email: cabo@tzi.org





Bormann & Leonard        Expires January 7, 2016               [Page 10]


Internet-Draft          CBOR Tags for ASN.1 OIDs               July 2015


   Sean Leonard
   Penango, Inc.
   5900 Wilshire Boulevard
   21st Floor
   Los Angeles, CA  90036
   USA

   Email: dev+ietf@seantek.com
   URI:   http://www.penango.com/










































Bormann & Leonard        Expires January 7, 2016               [Page 11]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/