< draft-bormann-cbor-tags-oid-00.txt		draft-bormann-cbor-tags-oid-01.txt >
	Network Working Group C. Bormann		Network Working Group C. Bormann
	Internet-Draft Universitaet Bremen TZI		Internet-Draft Universitaet Bremen TZI
	Intended status: Standards Track S. Leonard		Intended status: Standards Track S. Leonard
	Expires: April 30, 2015 Penango, Inc.		Expires: January 7, 2016 Penango, Inc.
	October 27, 2014		July 06, 2015
	Concise Binary Object Representation (CBOR) Tags for		Concise Binary Object Representation (CBOR) Tags for
	ASN.1 Object Identifiers		ASN.1 Object Identifiers
	draft-bormann-cbor-tags-oid-00		draft-bormann-cbor-tags-oid-01
	Abstract		Abstract
	The Concise Binary Object Representation (CBOR, RFC 7049) is a data		The Concise Binary Object Representation (CBOR, RFC 7049) is a data
	format whose design goals include the possibility of extremely small		format whose design goals include the possibility of extremely small
	code size, fairly small message size, and extensibility without the		code size, fairly small message size, and extensibility without the
	need for version negotiation.		need for version negotiation.
	The present document makes use of this extensibility to define CBOR		The present document makes use of this extensibility to define CBOR
	tags <<O>> and <<R>> [values TBD] for ASN.1 object identifiers. It		tags <<O>> and <<R>> [values TBD] for ASN.1 object identifiers. It
	skipping to change at page 1, line 40 ¶		skipping to change at page 1, line 40 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on April 30, 2015.		This Internet-Draft will expire on January 7, 2016.
	Copyright Notice		Copyright Notice
	Copyright (c) 2014 IETF Trust and the persons identified as the		Copyright (c) 2015 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. ASN.1 Object Identifiers . . . . . . . . . . . . . . . . . . 2		2. ASN.1 Object Identifiers . . . . . . . . . . . . . . . . . . 3
	3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 4		3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 4
	4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 6		4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 6
	5. Diagnostic Notation . . . . . . . . . . . . . . . . . . . . . 6		5. Diagnostic Notation . . . . . . . . . . . . . . . . . . . . . 7
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 8		7. Security Considerations . . . . . . . . . . . . . . . . . . . 8
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
	1. Introduction		1. Introduction
	The Concise Binary Object Representation (CBOR, [RFC7049]) provides		The Concise Binary Object Representation (CBOR, [RFC7049]) provides
	for the interchange of structured data without a requirement for a		for the interchange of structured data without a requirement for a
	pre-agreed schema. RFC 7049 defines a basic set of data types, as		pre-agreed schema. RFC 7049 defines a basic set of data types, as
	skipping to change at page 2, line 44 ¶		skipping to change at page 2, line 44 ¶
	encodings of both ASN.1 object identifiers and relative object		encodings of both ASN.1 object identifiers and relative object
	identifiers. The contents of these encodings can be carried in a		identifiers. The contents of these encodings can be carried in a
	CBOR byte string.		CBOR byte string.
	This document defines two CBOR tags that cover the two kinds of ASN.1		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		object identifiers encoded in this way. It is intended as the
	reference document for the IANA registration of the tags so defined.		reference document for the IANA registration of the tags so defined.
	1.1. Terminology		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		The terminology of RFC 7049 applies; in particular the term "byte" is
	used in its now customary sense as a synonym for "octet".		used in its now customary sense as a synonym for "octet".
	2. ASN.1 Object Identifiers		2. ASN.1 Object Identifiers
	The International Object Identifier tree [X.660] is a hierarchically		The International Object Identifier tree [X.660] is a hierarchically
	managed space of identifiers, each of which is uniquely represented		managed space of identifiers, each of which is uniquely represented
	as a sequence of unsigned integers ("sub-identifiers") [X.680].		as a sequence of unsigned integers ("sub-identifiers") [X.680].
	While these sequences can easily be represented in CBOR arrays of		While these sequences can easily be represented in CBOR arrays of
	unsigned integers, a more compact representation can often be		unsigned integers, a more compact representation can often be
	achieved by adopting the widely used representation of ASN.1 object		achieved by adopting the widely used representation of ASN.1 object
	identifiers defined in BER; this representation may also be more		identifiers defined in BER; this representation may also be more
	amenable to processing by other software making use of ASN.1 object		amenable to processing by other software making use of ASN.1 object
	identifiers.		identifiers.
	BER represents the sequence of unsigned integers by concatenating		BER represents the sequence of unsigned integers by concatenating
	self-delimiting [RFC6256] representations of each of the sub-		self-delimiting [RFC6256] representations of each of the sub-
	identifier in sequence.		identifier in sequence.
	skipping to change at page 5, line 46 ¶		skipping to change at page 6, line 7 ¶
	Figure 3: UUID in an object identifier, in BER		Figure 3: UUID in an object identifier, in BER
	C6 # 0b110_00110: mt 6, tag 6		C6 # 0b110_00110: mt 6, tag 6
	54 # 0b010_10100: mt 2, 20 bytes		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`		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		Figure 4: UUID in an object identifier, in CBOR
	3.3. Encoding of a MIB Relative OID		3.3. Encoding of a MIB Relative OID
	Given some OID (e.g., "lowpanMib", assumed to be "1.3.6.1.2.1.7001"),		Given some OID (e.g., "lowpanMib", assumed to be "1.3.6.1.2.1.226"
	to which the following is added:		[RFC7388]), to which the following is added:
	ASN.1 Value Notation (not suitable for diagnostic notation)		ASN.1 Value Notation (not suitable for diagnostic notation)
	{ lowpanObjects(1) lowpanStats(1) lowpanOutTransmits(29) }		{ lowpanObjects(1) lowpanStats(1) lowpanOutTransmits(29) }
	Dotted Decimal Notation (diagnostic notation; see Section 5)		Dotted Decimal Notation (diagnostic notation; see Section 5)
	.1.1.29		.1.1.29
	0D # UNIVERSAL TAG 13		0D # UNIVERSAL TAG 13
	03 # 3 bytes, primitive		03 # 3 bytes, primitive
	01 01 1D # X.690 Clause 8.20		01 01 1D # X.690 Clause 8.20
	# 1 1 29 show component encoding		# 1 1 29 show component encoding
	Figure 5: MIB relative object identifier, in BER		Figure 5: MIB relative object identifier, in BER
	skipping to change at page 7, line 36 ¶		skipping to change at page 8, line 5 ¶
	Table 1: Examples for extended diagnostic notation		Table 1: Examples for extended diagnostic notation
	6. IANA Considerations		6. IANA Considerations
	(This section to be edited by the RFC editor.)		(This section to be edited by the RFC editor.)
	IANA is requested to assign the CBOR tags in Table 2, with the		IANA is requested to assign the CBOR tags in Table 2, with the
	present document as the specification reference.		present document as the specification reference.
	+----------+------------+-------------------------------------------+		+----------+-------------+------------------------------------------+
	| Tag | Data Item | Semantics |		| Tag | Data Item | Semantics |
	+----------+------------+-------------------------------------------+		+----------+-------------+------------------------------------------+
	| 6<<TBD>> | byte | ASN.1 object identifier (absolute, in BER |		| 6<<TBD>> | byte string | ASN.1 object identifier (absolute, in |
	| | string | encoding) |		| | | BER encoding) |
	| 7<<TBD>> | byte | ASN.1 object identifier (relative, in BER |		| 7<<TBD>> | byte string | ASN.1 object identifier (relative, in |
	| | string | encoding) |		| | | BER encoding) |
	+----------+------------+-------------------------------------------+		+----------+-------------+------------------------------------------+
	Table 2: Values for Tags		Table 2: Values for Tags
	6.1. Discussion		6.1. Discussion
	(This subsection to be removed by the RFC editor.)		(This subsection to be removed by the RFC editor.)
	The space for single-byte tags in CBOR (0..23) is severely limited.		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		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		one less byte per instance outweigh the consumption of two values in
	this code point space.		this code point space.
	Procedurally, this space is also reserved for standards action.		Procedurally, this space is also reserved for standards action.
	An alternative would be to go for the specification required space,		An alternative would be to go for the specification required space,
	e.g. tag number 40 for <<O>> and tag number 41 for <<O>>. As an		e.g. tag number 40 for <<O>> and tag number 41 for <<R>>. As an
	example this would change Figure 2 into:		example this would change Figure 2 into:
	d8 28 # tag(40)		d8 28 # tag(40)
	49 # bytes(9)		49 # bytes(9)
	60 86 48 01 65 03 04 02 01 #		60 86 48 01 65 03 04 02 01 #
	Figure 7: SHA-256 OID in cbor (using specification required tag)		Figure 7: SHA-256 OID in cbor (using specification required tag)
	7. Security Considerations		7. Security Considerations
	skipping to change at page 9, line 7 ¶		skipping to change at page 9, line 22 ¶
	7.1. Conversions Between BER and Dotted Decimal Notation		7.1. Conversions Between BER and Dotted Decimal Notation
	[PKILCAKE] uncovers exploit vectors for the illegal values above, as		[PKILCAKE] uncovers exploit vectors for the illegal values above, as
	well as for cases in which conversion to or from the dotted decimal		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		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		on the range of unsigned integer values for an arc; the integers are
	arbitrarily valued. An implementation SHOULD NOT attempt to convert		arbitrarily valued. An implementation SHOULD NOT attempt to convert
	each component using a fixed-size accumulator, as an attacker will		each component using a fixed-size accumulator, as an attacker will
	certainly be able to cause the accumulator to overflow. Compact and		certainly be able to cause the accumulator to overflow. Compact and
	efficient techniques for such conversions, such as the double dabble		efficient techniques for such conversions, such as the double dabble
	algorithm [[TODO: CITE]], are well-known in the art; their		algorithm [DOUBLEDABBLE] are well-known in the art; their application
	application to this field is left as an exercise to the reader.		to this field is left as an exercise to the reader.
	8. References		8. References
	8.1. Normative 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		[RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object
	Representation (CBOR)", RFC 7049, October 2013.		Representation (CBOR)", RFC 7049, October 2013.
	[X.660] International Telecommunications Union, "Information		[X.660] International Telecommunications Union, "Information
	technology -- Procedures for the operation of object		technology -- Procedures for the operation of object
	identifier registration authorities: General procedures		identifier registration authorities: General procedures
	and top arcs of the international object identifier tree",		and top arcs of the international object identifier tree",
	ITU-T Recommendation X.660, July 2011.		ITU-T Recommendation X.660, July 2011.
	[X.680] International Telecommunications Union, "Information		[X.680] International Telecommunications Union, "Information
	skipping to change at page 9, line 41 ¶		skipping to change at page 10, line 12 ¶
	Distinguished Encoding Rules (DER)", ITU-T Recommendation		Distinguished Encoding Rules (DER)", ITU-T Recommendation
	X.690, November 2008.		X.690, November 2008.
	8.2. Informative References		8.2. Informative References
	[CCITT.X208.1988]		[CCITT.X208.1988]
	International Telephone and Telegraph Consultative		International Telephone and Telegraph Consultative
	Committee, "Specification of Abstract Syntax Notation One		Committee, "Specification of Abstract Syntax Notation One
	(ASN.1)", CCITT Recommendation X.208, November 1988.		(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,		[OIDINFO] Orange SA, "OID Repository", 2014,
	<http://www.oid-info.com/>.		<http://www.oid-info.com/>.
	[PKILCAKE]		[PKILCAKE]
	Kaminsky, D., Patterson, M., and L. Sassaman, "PKI Layer		Kaminsky, D., Patterson, M., and L. Sassaman, "PKI Layer
	Cake: New Collision Attacks Against the Global X.509		Cake: New Collision Attacks Against the Global X.509
	Infrastructure", FC 2010, Lecture Notes in Computer		Infrastructure", FC 2010, Lecture Notes in Computer
	Science 6052 289-303, January 2010,		Science 6052 289-303, DOI: 10.1007/978-3-642-14577-3_22,
	<http://dl.acm.org/citation.cfm?id=2163593>.		January 2010, <http://dl.acm.org/citation.cfm?id=2163593>.
	doi:10.1007/978-3-642-14577-3_22
	[RFC6256] Eddy, W. and E. Davies, "Using Self-Delimiting Numeric		[RFC6256] Eddy, W. and E. Davies, "Using Self-Delimiting Numeric
	Values in Protocols", RFC 6256, May 2011.		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		[X.672] International Telecommunications Union, "Information
	technology -- Open systems interconnection -- Object		technology -- Open systems interconnection -- Object
	identifier resolution system", ITU-T Recommendation X.672,		identifier resolution system", ITU-T Recommendation X.672,
	August 2010.		August 2010.
	Authors' Addresses		Authors' Addresses
	Carsten Bormann		Carsten Bormann
	Universitaet Bremen TZI		Universitaet Bremen TZI
	Postfach 330440		Postfach 330440
End of changes. 18 change blocks.
	25 lines changed or deleted		42 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/