Concise Binary Object Representation (CBOR) Tags for ASN.1 Object Identifiers
draft-bormann-cbor-tags-oid-02
The information below is for an old version of the document.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Carsten Bormann , Sean Leonard | ||
| Last updated | 2016-01-06 | ||
| Replaced by | draft-ietf-cbor-tags-oid, RFC 9090 | ||
| Stream | (None) | ||
| Formats | plain text htmlized pdfized bibtex | ||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-bormann-cbor-tags-oid-02
Network Working Group C. Bormann
Internet-Draft Universitaet Bremen TZI
Intended status: Standards Track S. Leonard
Expires: July 9, 2016 Penango, Inc.
January 06, 2016
Concise Binary Object Representation (CBOR) Tags for
ASN.1 Object Identifiers
draft-bormann-cbor-tags-oid-02
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 July 9, 2016.
Copyright Notice
Copyright (c) 2016 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 July 9, 2016 [Page 1]
Internet-Draft CBOR Tags for ASN.1 OIDs January 2016
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 . . . . . . . . . . . . . . . . . . . . . . . 11
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]) specify 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", "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 July 9, 2016 [Page 2]
Internet-Draft CBOR Tags for ASN.1 OIDs January 2016
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-
identifiers 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 July 9, 2016 [Page 3]
Internet-Draft CBOR Tags for ASN.1 OIDs January 2016
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 <<R>>. See Section 6.1.
Bormann & Leonard Expires July 9, 2016 [Page 4]
Internet-Draft CBOR Tags for ASN.1 OIDs January 2016
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(184830721219540099336690027854602552603) }
Dotted Decimal Notation (also XML Value Notation)
2.25.184830721219540099336690027854602552603
06 # UNIVERSAL TAG 6
14 # 20 bytes, primitive
69 82 96 8D 8D 88 9B CC A8 C7 B3 BD D4 C0 80 AA AE D7 8A 1B
# | 184830721219540099336690027854602552603
# 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 82 96 8D 8D 88 9B CC A8 C7 B3 BD D4 C0 80 AA AE D7 8A 1B
Figure 4: UUID in an object identifier, in CBOR
Bormann & Leonard Expires July 9, 2016 [Page 5]
Internet-Draft CBOR Tags for ASN.1 OIDs January 2016
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]. (This preliminary
conclusion is likely to generate some discussion, see Section 6.1.)
Bormann & Leonard Expires July 9, 2016 [Page 6]
Internet-Draft CBOR Tags for ASN.1 OIDs January 2016
5. Diagnostic Notation
Implementers will likely want to see OIDs and relative OIDs in their
"natural forms" (as sequences of decimal 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'2b0601') | 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 July 9, 2016 [Page 7]
Internet-Draft CBOR Tags for ASN.1 OIDs January 2016
+----------+-------------+------------------------------------------+
| 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 July 9, 2016 [Page 8]
Internet-Draft CBOR Tags for ASN.1 OIDs January 2016
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, DOI 10.17487/
RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049,
October 2013, <http://www.rfc-editor.org/info/rfc7049>.
[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.
Bormann & Leonard Expires July 9, 2016 [Page 9]
Internet-Draft CBOR Tags for ASN.1 OIDs January 2016
[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.
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, DOI 10.17487/RFC6256, May
2011, <http://www.rfc-editor.org/info/rfc6256>.
[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, DOI
10.17487/RFC7388, October 2014,
<http://www.rfc-editor.org/info/rfc7388>.
[X.672] International Telecommunications Union, "Information
technology -- Open systems interconnection -- Object
identifier resolution system", ITU-T Recommendation X.672,
August 2010.
Bormann & Leonard Expires July 9, 2016 [Page 10]
Internet-Draft CBOR Tags for ASN.1 OIDs January 2016
Authors' Addresses
Carsten Bormann
Universitaet Bremen TZI
Postfach 330440
Bremen D-28359
Germany
Phone: +49-421-218-63921
Email: cabo@tzi.org
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 July 9, 2016 [Page 11]