draft-ietf-cbor-tags-oid-06.txt   draft-ietf-cbor-tags-oid-07.txt 
Network Working Group C. Bormann Network Working Group C. Bormann
Internet-Draft Universität Bremen TZI Internet-Draft Universität Bremen TZI
Intended status: Standards Track 30 March 2021 Intended status: Standards Track 19 May 2021
Expires: 1 October 2021 Expires: 20 November 2021
Concise Binary Object Representation (CBOR) Tags for Object Identifiers Concise Binary Object Representation (CBOR) Tags for Object Identifiers
draft-ietf-cbor-tags-oid-06 draft-ietf-cbor-tags-oid-07
Abstract Abstract
The Concise Binary Object Representation (CBOR, RFC 8949) is a data The Concise Binary Object Representation (CBOR, RFC 8949) 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 defines CBOR tags for object identifiers (OIDs). The present document defines CBOR tags for object identifiers (OIDs).
It is intended as the reference document for the IANA registration of It is intended as the reference document for the IANA registration of
skipping to change at page 1, line 37 skipping to change at page 1, line 37
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 1 October 2021. This Internet-Draft will expire on 20 November 2021.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 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 (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text extracted from this document must include Simplified BSD License text
as described in Section 4.e of the Trust Legal Provisions and are as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License. provided without warranty as described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Object Identifiers . . . . . . . . . . . . . . . . . . . . . 3 2. Object Identifiers . . . . . . . . . . . . . . . . . . . . . 3
3. Basic Examples . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Requirements on the byte string being tagged . . . . . . 5
4. Tag Factoring with Arrays and Maps . . . . . . . . . . . . . 7 2.2. Preferred Serialization Considerations . . . . . . . . . 6
5. CDDL Control Operators . . . . . . . . . . . . . . . . . . . 9 2.3. Discussion . . . . . . . . . . . . . . . . . . . . . . . 6
6. CDDL typenames . . . . . . . . . . . . . . . . . . . . . . . 10 3. Basic Examples . . . . . . . . . . . . . . . . . . . . . . . 6
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 3.1. Encoding of the SHA-256 OID . . . . . . . . . . . . . . . 6
8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 3.2. Encoding of a MIB Relative OID . . . . . . . . . . . . . 7
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 4. Tag Factoring with Arrays and Maps . . . . . . . . . . . . . 8
9.1. Normative References . . . . . . . . . . . . . . . . . . 12 4.1. Preferred Serialization Considerations . . . . . . . . . 8
9.2. Informative References . . . . . . . . . . . . . . . . . 13 4.2. Tag Factoring Example: X.500 Distinguished Name . . . . . 8
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 13 5. CDDL Control Operators . . . . . . . . . . . . . . . . . . . 10
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 15 6. CDDL typenames . . . . . . . . . . . . . . . . . . . . . . . 11
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 15 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16 7.1. CBOR Tags . . . . . . . . . . . . . . . . . . . . . . . . 11
7.2. CDDL Control Operators . . . . . . . . . . . . . . . . . 12
8. Security Considerations . . . . . . . . . . . . . . . . . . . 12
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
9.1. Normative References . . . . . . . . . . . . . . . . . . 13
9.2. Informative References . . . . . . . . . . . . . . . . . 14
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 15
A.1. Changes from -06 to -07 . . . . . . . . . . . . . . . . . 15
A.2. Changes from -05 to -06 . . . . . . . . . . . . . . . . . 15
A.3. Changes from -04 to -05 . . . . . . . . . . . . . . . . . 15
A.4. Changes from -03 to -04 . . . . . . . . . . . . . . . . . 15
A.5. Changes from -02 to -03 . . . . . . . . . . . . . . . . . 15
A.6. Changes from -01 to -02 . . . . . . . . . . . . . . . . . 15
A.7. Changes from -00 to -01 . . . . . . . . . . . . . . . . . 15
A.8. Changes from -07 (bormann) to -00 (ietf) . . . . . . . . 16
A.9. Changes from -06 to -07 . . . . . . . . . . . . . . . . . 16
A.10. Changes from -05 to -06 . . . . . . . . . . . . . . . . . 16
A.11. Changes from -04 to -05 . . . . . . . . . . . . . . . . . 16
A.12. Changes from -03 to -04 . . . . . . . . . . . . . . . . . 16
A.13. Changes from -02 to -03 . . . . . . . . . . . . . . . . . 16
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 17
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction 1. Introduction
The Concise Binary Object Representation (CBOR, [RFC8949]) provides The Concise Binary Object Representation (CBOR, [RFC8949]) 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. [RFC8949] defines a basic set of data types, as pre-agreed schema. [RFC8949] defines a basic set of data types, as
well as a tagging mechanism that enables extending the set of data well as a tagging mechanism that enables extending the set of data
types supported via an IANA registry. types supported via an IANA registry.
The present document defines CBOR tags for object identifiers (OIDs, The present document defines CBOR tags for object identifiers (OIDs,
skipping to change at page 3, line 15 skipping to change at page 3, line 36
1.1. Terminology 1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
The terminology of [RFC8949] applies; in particular the term "byte" The terminology of [RFC8949] applies; in particular the term "byte"
is used in its now customary sense as a synonym for "octet". The is used in its now customary sense as a synonym for "octet". The
term "SDNV" is used as defined in [RFC6256]. term "SDNV" (Self-Delimiting Numeric Value) is used as defined in
[RFC6256], with the additional restriction detailed in Section 2.1
(no leading zeros).
2. Object Identifiers 2. 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 integer values [X.680]. (These integer as a sequence of unsigned integer values [X.680]. (These integer
values are called "primary integer values" in X.660 because they can values are called "primary integer values" in X.660 because they can
be accompanied by (not necessarily unambiguous) secondary be accompanied by (not necessarily unambiguous) secondary
identifiers. We ignore the latter and simply use the term "integer identifiers. We ignore the latter and simply use the term "integer
values" here, occasionally calling out their unsignedness. We also values" here, occasionally calling out their unsignedness. We also
use the term "arc" when the focus is on the edge of the tree labeled use the term "arc" when the focus is on the edge of the tree labeled
by such an integer value, as well as in the sense of a "long arc", by such an integer value, as well as in the sense of a "long arc",
i.e. a (sub)sequence of such integer values.) i.e., a (sub)sequence of such integer values.)
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 object achieved by adopting the widely used representation of 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 that makes use of object amenable to processing by other software that makes use of 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 integer self-delimiting [RFC6256] representations of each of the integer
values in sequence. values in sequence.
skipping to change at page 4, line 11 skipping to change at page 4, line 34
arc "joint-iso-itu-t(2)" has no such limitations on its second arc.) arc "joint-iso-itu-t(2)" has no such limitations on its second arc.)
If X and Y are the first two integer values, the single integer value If X and Y are the first two integer values, the single integer value
actually encoded is computed as: actually encoded is computed as:
X * 40 + Y X * 40 + Y
The inverse transformation (again making use of the known ranges of X The inverse transformation (again making use of the known ranges of X
and Y) is applied when decoding the object identifier. and Y) is applied when decoding the object identifier.
Since the semantics of absolute and relative object identifiers Since the semantics of absolute and relative object identifiers
differ, this specification defines two tags, collectively called the differ, and it is very common for companies to use self-assigned
"OID tags" here: numbers under the arc "1.3.6.1.4.1" (IANA Private Enterprise Number
OID, [IANA.enterprise-numbers]) that adds 5 fixed bytes to an encoded
OID value, this specification defines three tags, collectively called
the "OID tags" here:
Tag TBD111: tags a byte string as the [X.690] encoding of an absolute Tag TBD111: tags a byte string as the [X.690] encoding of an absolute
object identifier (simply "object identifier" or "OID"). object identifier (simply "object identifier" or "OID").
Tag TBD110: tags a byte string as the [X.690] encoding of a relative Tag TBD110: tags a byte string as the [X.690] encoding of a relative
object identifier (also "relative OID"). Since the encoding of each object identifier (also "relative OID"). Since the encoding of each
number is the same as for [RFC6256] Self-Delimiting Numeric Values number is the same as for [RFC6256] Self-Delimiting Numeric Values
(SDNVs), this tag can also be used for tagging a byte string that (SDNVs), this tag can also be used for tagging a byte string that
contains a sequence of zero or more SDNVs. contains a sequence of zero or more SDNVs (or a more application-
specific tag can be created for such an application).
Tag TBD112: structurally like TBD110, but understood to be relative Tag TBD112: structurally like TBD110, but understood to be relative
to "1.3.6.1.4.1" (IANA Private Enterprise Number OID, to "1.3.6.1.4.1" (IANA Private Enterprise Number OID,
[IANA.enterprise-numbers]). Hence, the semantics of the result are [IANA.enterprise-numbers]). Hence, the semantics of the result are
that of an absolute object identifier. that of an absolute object identifier.
2.1. Requirements on the byte string being tagged 2.1. Requirements on the byte string being tagged
To form a valid tag, a byte string tagged by TBD111, TBD110, or To form a valid tag, a byte string tagged by TBD111, TBD110, or
TBD112 MUST be syntactically valid contents (the value part) for a TBD112 MUST be syntactically valid contents (the value part) for a
skipping to change at page 5, line 30 skipping to change at page 6, line 12
For byte strings with tag TBD111: For byte strings with tag TBD111:
"/^(([\x81-\xFF][\x80-\xFF]*)?[\x00-\x7F])+$/" "/^(([\x81-\xFF][\x80-\xFF]*)?[\x00-\x7F])+$/"
For byte strings with tag TBD110 or TBD112: For byte strings with tag TBD110 or TBD112:
"/^(([\x81-\xFF][\x80-\xFF]*)?[\x00-\x7F])*$/" "/^(([\x81-\xFF][\x80-\xFF]*)?[\x00-\x7F])*$/"
A tag with tagged content that does not conform to the applicable A tag with tagged content that does not conform to the applicable
regexp is invalid. regular expression is invalid.
2.2. Discussion 2.2. Preferred Serialization Considerations
For an absolute OID with a prefix of "1.3.6.1.4.1", representations
with both the TBD111 and TBD112 tags are applicable, where the
representation with TBD112 will be five bytes shorter (by leaving out
the prefix h'2b06010401' from the enclosed byte string). This
specification makes that shorter representation the preferred
serialization (see Sections 3.4 and 4.1 of [RFC8949]). Note that
this also implies that the Core Deterministic Encoding Requirements
(Section 4.2.1 of [RFC8949]) require the use of TBD112 tags instead
of TBD111 wherever that is possible.
2.3. Discussion
Staying close to the way object identifiers are encoded in ASN.1 BER Staying close to the way object identifiers are encoded in ASN.1 BER
makes back-and-forth translation easy; otherwise we would choose a makes back-and-forth translation easy; otherwise we would choose a
more efficient encoding. Object identifiers in IETF protocols are more efficient encoding. Object identifiers in IETF protocols are
serialized in dotted decimal form or BER form, so there is an serialized in dotted decimal form or BER form, so there is an
advantage in not inventing a third form. Also, expectations of the advantage in not inventing a third form. Also, expectations of the
cost of encoding object identifiers are based on BER; using a cost of encoding object identifiers are based on BER; using a
different encoding might not be aligned with these expectations. If different encoding might not be aligned with these expectations. If
additional information about an OID is desired, lookup services such additional information about an OID is desired, lookup services such
as the OID Resolution Service (ORS) [X.672] and the OID Repository as the OID Resolution Service (ORS) [X.672] and the OID Repository
skipping to change at page 6, line 49 skipping to change at page 7, line 41
Dotted Decimal Notation: .1.1.29 Dotted Decimal Notation: .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 3: MIB relative object identifier, in BER Figure 3: MIB relative object identifier, in BER
D8 6E # tag(110) D8 6E # tag(110)
43 # 0b010_01001: mt 2 (bstr), 3 bytes 43 # 0b010_00011: mt 2 (bstr), 3 bytes
01 01 1D # X.690 Clause 8.20 01 01 1D # X.690 Clause 8.20
Figure 4: MIB relative object identifier, in CBOR Figure 4: MIB relative object identifier, in CBOR
This relative OID saves seven bytes compared to the full OID This relative OID saves seven bytes compared to the full OID
encoding. encoding.
4. Tag Factoring with Arrays and Maps 4. Tag Factoring with Arrays and Maps
OID tags can tag byte strings (as discussed above), but also CBOR OID tags can tag byte strings (as discussed above), but also CBOR
skipping to change at page 7, line 34 skipping to change at page 8, line 31
is imputed to all keys in the map that are byte strings, arrays, or is imputed to all keys in the map that are byte strings, arrays, or
maps; again, there is no effect on keys of other major types. Note maps; again, there is no effect on keys of other major types. Note
that there is also no effect on the values in the map. that there is also no effect on the values in the map.
As a result of these rules, tag factoring in nested arrays and maps As a result of these rules, tag factoring in nested arrays and maps
is supported. For example, a 3-dimensional array of OIDs can be is supported. For example, a 3-dimensional array of OIDs can be
composed by using a single TBD111 tag containing an array of arrays composed by using a single TBD111 tag containing an array of arrays
of arrays of byte strings. All such byte strings are then considered of arrays of byte strings. All such byte strings are then considered
OIDs. OIDs.
4.1. Tag Factoring Example: X.500 Distinguished Name 4.1. Preferred Serialization Considerations
Where tag factoring with tag TBD111 is used, some OIDs enclosed in
the tag may be encoded in a shorter way by using tag TBD112 instead
of encoding an unadorned byte string. This remains the preferred
serialization (see also Section 2.2). However, this specification
does not make the presence or absence of tag factoring a preferred
serialization; application protocols can define where tag factoring
is to be used or not (and will need to do so if they have
deterministic encoding requirements).
4.2. Tag Factoring Example: X.500 Distinguished Name
Consider the X.500 distinguished name: Consider the X.500 distinguished name:
+==============================+=============+ +==============================+=============+
| Attribute Types | Attribute | | Attribute Types | Attribute |
| | Values | | | Values |
+==============================+=============+ +==============================+=============+
| c (2.5.4.6) | US | | c (2.5.4.6) | US |
+------------------------------+-------------+ +------------------------------+-------------+
| l (2.5.4.7) | Los Angeles | | l (2.5.4.7) | Los Angeles |
skipping to change at page 8, line 26 skipping to change at page 9, line 26
| | St | | | St |
+------------------------------+-------------+ +------------------------------+-------------+
| businessCategory (2.5.4.15) | Public Park | | businessCategory (2.5.4.15) | Public Park |
| buildingName | Pershing | | buildingName | Pershing |
| (0.9.2342.19200300.100.1.48) | Square | | (0.9.2342.19200300.100.1.48) | Square |
+------------------------------+-------------+ +------------------------------+-------------+
Table 1: Example X.500 Distinguished Name Table 1: Example X.500 Distinguished Name
Table 1 has four "relative distinguished names" (RDNs). The country Table 1 has four "relative distinguished names" (RDNs). The country
and street RDNs are single-valued. The second and fourth RDNs are (first) and street (third) RDNs are single-valued. The second and
multi-valued. fourth RDNs are multi-valued.
The equivalent representations in CBOR diagnostic notation (Section 8 The equivalent representations in CBOR diagnostic notation (Section 8
of [RFC8949]) and CBOR are: of [RFC8949]) and CBOR are:
111([{ h'550406': "US" }, 111([{ h'550406': "US" },
{ h'550407': "Los Angeles", h'550408': "CA", { h'550407': "Los Angeles",
h'550408': "CA",
h'550411': "90013" }, h'550411': "90013" },
{ h'550409': "532 S Olive St" }, { h'550409': "532 S Olive St" },
{ h'55040f': "Public Park", { h'55040f': "Public Park",
h'0992268993f22c640130': "Pershing Square" }]) h'0992268993f22c640130': "Pershing Square" }])
Figure 5: Distinguished Name, in CBOR Diagnostic Notation Figure 5: Distinguished Name, in CBOR Diagnostic Notation
d8 6f # tag(111) d8 6f # tag(111)
84 # array(4) 84 # array(4)
a1 # map(1) a1 # map(1)
skipping to change at page 9, line 41 skipping to change at page 10, line 41
5065727368696e6720537175617265 # "Pershing Square" 5065727368696e6720537175617265 # "Pershing Square"
Figure 6: Distinguished Name, in CBOR (109 bytes) Figure 6: Distinguished Name, in CBOR (109 bytes)
(This example encoding assumes that all attribute values are UTF-8 (This example encoding assumes that all attribute values are UTF-8
strings, or can be represented as UTF-8 strings with no loss of strings, or can be represented as UTF-8 strings with no loss of
information.) information.)
5. CDDL Control Operators 5. CDDL Control Operators
CDDL specifications may want to specify the use of SDNVs or SDNV Concise Data Definition Language (CDDL [RFC8610]) specifications may
sequences (as defined for the tag content for TBD110). This document want to specify the use of SDNVs or SDNV sequences (as defined for
introduces two new control operators that can be applied to a target the tag content for TBD110). This document introduces two new
value that is a byte string: control operators that can be applied to a target value that is a
byte string:
* ".sdnv", with a control type that contains unsigned integers. The * ".sdnv", with a control type that contains unsigned integers. The
byte string is specified to be encoded as an [RFC6256] SDNV (BER byte string is specified to be encoded as an [RFC6256] SDNV (BER
encoding) for the matching values of the control type. encoding) for the matching values of the control type.
* ".sdnvseq", with a control type that contains arrays of unsigned * ".sdnvseq", with a control type that contains arrays of unsigned
integers. The byte string is specified to be encoded as a integers. The byte string is specified to be encoded as a
sequence of [RFC6256] SDNVs (BER encoding) that decodes to an sequence of [RFC6256] SDNVs (BER encoding) that decodes to an
array of unsigned integers matching the control type. array of unsigned integers matching the control type.
skipping to change at page 10, line 35 skipping to change at page 11, line 35
country-value = text .size 2 country-value = text .size 2
Figure 8: Using .oid Figure 8: Using .oid
Note that the control type need not be a literal; e.g., "bytes .oid Note that the control type need not be a literal; e.g., "bytes .oid
[2, 5, 4, *uint]" matches all OIDs inside OID arc 2.5.4, [2, 5, 4, *uint]" matches all OIDs inside OID arc 2.5.4,
"attributeType". "attributeType".
6. CDDL typenames 6. CDDL typenames
For the use with CDDL [RFC8610], the typenames defined in Figure 9 For the use with CDDL, the typenames defined in Figure 9 are
are recommended: recommended:
oid = #6.111(bstr) oid = #6.111(bstr)
roid = #6.110(bstr) roid = #6.110(bstr)
pen = #6.112(bstr) pen = #6.112(bstr)
Figure 9: Recommended typenames for CDDL Figure 9: Recommended typenames for CDDL
7. IANA Considerations 7. IANA Considerations
7.1. CBOR Tags 7.1. CBOR Tags
IANA is requested to assign the CBOR tags in Table 2, with the IANA is requested to assign in the 1+1 byte space (24..255) of the
present document as the specification reference. CBOR tags registry [IANA.cbor-tags] the CBOR tags in Table 2, with
the present document as the specification reference.
+========+================+============================+ +========+================+============================+============+
| Tag | Data Item | Semantics | | Tag | Data Item | Semantics | Reference |
+========+================+============================+ +========+================+============================+============+
| TBD111 | byte string or | object identifier (BER | | TBD111 | byte string | object identifier (BER | [this |
| | array or map | encoding) | | | or array or | encoding) | document, |
+--------+----------------+----------------------------+ | | map | | Section 2] |
| TBD110 | byte string or | relative object identifier | +--------+----------------+----------------------------+------------+
| | array or map | (BER encoding); | | TBD110 | byte string | relative object identifier | [this |
| | | SDNV [RFC6256] sequence | | | or array or | (BER encoding); | document, |
+--------+----------------+----------------------------+ | | map | SDNV [RFC6256] sequence | Section 2] |
| TBD112 | byte string or | object identifier (BER | +--------+----------------+----------------------------+------------+
| | array or map | encoding), relative to | | TBD112 | byte string | object identifier (BER | [this |
| | | 1.3.6.1.4.1 | | | or array or | encoding), relative to | document, |
+--------+----------------+----------------------------+ | | map | 1.3.6.1.4.1 | Section 2] |
+--------+----------------+----------------------------+------------+
Table 2: Values for New Tags Table 2: Values for New Tags
7.2. CDDL Control Operators 7.2. CDDL Control Operators
IANA is requested to assign the CDDL Control Operators in Table 3, IANA is requested to assign in the CDDL Control Operators registry
with the present document as the specification reference. [IANA.cddl] the CDDL Control Operators in Table 3, with the present
document as the specification reference.
+==========+============================+ +==========+============================+
| Name | Reference | | Name | Reference |
+==========+============================+ +==========+============================+
| .sdnv | [this document, Section 5] | | .sdnv | [this document, Section 5] |
+----------+----------------------------+ +----------+----------------------------+
| .sdnvseq | [this document, Section 5] | | .sdnvseq | [this document, Section 5] |
+----------+----------------------------+ +----------+----------------------------+
| .oid | [this document, Section 5] | | .oid | [this document, Section 5] |
+----------+----------------------------+ +----------+----------------------------+
skipping to change at page 12, line 15 skipping to change at page 13, line 15
OIDs and relative OIDs can always be treated as opaque byte strings. OIDs and relative OIDs can always be treated as opaque byte strings.
Actually understanding the structure that was used for generating Actually understanding the structure that was used for generating
them is not necessary, and, except for checking the structure them is not necessary, and, except for checking the structure
requirements, it is strongly NOT RECOMMENDED to perform any requirements, it is strongly NOT RECOMMENDED to perform any
processing of this kind (e.g., converting into dotted notation and processing of this kind (e.g., converting into dotted notation and
back) unless absolutely necessary. If the OIDs are translated into back) unless absolutely necessary. If the OIDs are translated into
other representations, the usual security considerations for non- other representations, the usual security considerations for non-
trivial representation conversions apply; the integer values are trivial representation conversions apply; the integer values are
unlimited in range. unlimited in range.
An attacker might trick an application into using a byte string
inside a tag-factored data item, where the byte string is not
actually intended to fall under one of the tags defined here. This
may cause the application to emit data with semantics different from
what was intended. Applications therefore need to be restrictive
with respect to what data items they apply tag factoring to.
9. References 9. References
9.1. Normative References 9.1. Normative References
[IANA.cbor-tags]
IANA, "Concise Binary Object Representation (CBOR) Tags",
<http://www.iana.org/assignments/cbor-tags>.
[IANA.cddl]
IANA, "Concise Data Definition Language (CDDL)",
<http://www.iana.org/assignments/cddl>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[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, DOI 10.17487/RFC6256, May Values in Protocols", RFC 6256, DOI 10.17487/RFC6256, May
2011, <https://www.rfc-editor.org/info/rfc6256>. 2011, <https://www.rfc-editor.org/info/rfc6256>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
skipping to change at page 13, line 19 skipping to change at page 14, line 31
[X.690] International Telecommunications Union, "Information [X.690] International Telecommunications Union, "Information
technology — ASN.1 encoding rules: Specification of Basic technology — ASN.1 encoding rules: Specification of Basic
Encoding Rules (BER), Canonical Encoding Rules (CER) and Encoding Rules (BER), Canonical Encoding Rules (CER) and
Distinguished Encoding Rules (DER)", ITU-T Recommendation Distinguished Encoding Rules (DER)", ITU-T Recommendation
X.690, August 2015, <https://www.itu.int/rec/T-REC-X.690>. X.690, August 2015, <https://www.itu.int/rec/T-REC-X.690>.
9.2. Informative References 9.2. Informative References
[IANA.enterprise-numbers] [IANA.enterprise-numbers]
IANA, "enterprise-numbers", IANA, "Enterprise Numbers",
<http://www.iana.org/assignments/enterprise-numbers>. <http://www.iana.org/assignments/enterprise-numbers>.
[OID-INFO] Orange SA, "OID Repository", 2016, [OID-INFO] Orange SA, "OID Repository", 2016,
<http://www.oid-info.com/>. <http://www.oid-info.com/>.
[PCRE] Ho, A., "PCRE - Perl Compatible Regular Expressions", [PCRE] Ho, A., "PCRE - Perl Compatible Regular Expressions",
2018, <http://www.pcre.org/>. 2018, <http://www.pcre.org/>.
[RFC7388] Schoenwaelder, J., Sehgal, A., Tsou, T., and C. Zhou, [RFC7388] Schoenwaelder, J., Sehgal, A., Tsou, T., and C. Zhou,
"Definition of Managed Objects for IPv6 over Low-Power "Definition of Managed Objects for IPv6 over Low-Power
skipping to change at page 13, line 43 skipping to change at page 15, line 9
[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, <https://www.itu.int/rec/T-REC-X.672>. August 2010, <https://www.itu.int/rec/T-REC-X.672>.
Appendix A. Change Log Appendix A. Change Log
This section is to be removed before publishing as an RFC. This section is to be removed before publishing as an RFC.
A.1. Changes from -05 to -06 A.1. Changes from -06 to -07
* Various editorial changes prompted by IESG feedback; clarify the
usage of "SDNV" in this document (no leading zeros).
* Add security consideration about tag-factoring.
* Make TBD112, where applicable, the preferred serialization (and
thus the required deterministic encoding) over TBD111.
A.2. Changes from -05 to -06
Add references to specific section numbers of [X.690] to better Add references to specific section numbers of [X.690] to better
explain validity of enclosed byte string. explain validity of enclosed byte string.
A.2. Changes from -04 to -05 A.3. Changes from -04 to -05
* Update acknowledgements, contributor list, and author list * Update acknowledgements, contributor list, and author list
A.3. Changes from -03 to -04 A.4. Changes from -03 to -04
Process WGLC and shepherd comments: Process WGLC and shepherd comments:
* Update references (RFC 8949, URIs for ITU-T) * Update references (RFC 8949, URIs for ITU-T)
* Define arc for this document, reference SDN definition * Define arc for this document, reference SDN definition
* Restructure, small editorial clarifications * Restructure, small editorial clarifications
A.4. Changes from -02 to -03 A.5. Changes from -02 to -03
* Add tag TBD112 for PEN-relative OIDs * Add tag TBD112 for PEN-relative OIDs
* Add suggested CDDL typenames; reference RFC8610 * Add suggested CDDL typenames; reference RFC8610
A.5. Changes from -01 to -02 A.6. Changes from -01 to -02
Minor editorial changes, remove some remnants, ready for WGLC. Minor editorial changes, remove some remnants, ready for WGLC.
A.6. Changes from -00 to -01 A.7. Changes from -00 to -01
Clean up OID tag factoring. Clean up OID tag factoring.
A.7. Changes from -07 (bormann) to -00 (ietf) A.8. Changes from -07 (bormann) to -00 (ietf)
Resubmitted as WG draft after adoption. Resubmitted as WG draft after adoption.
A.8. Changes from -06 to -07 A.9. Changes from -06 to -07
Reduce the draft back to its basic mandate: Describe CBOR tags for Reduce the draft back to its basic mandate: Describe CBOR tags for
what is colloquially know as ASN.1 Object IDs. what is colloquially know as ASN.1 Object IDs.
A.9. Changes from -05 to -06 A.10. Changes from -05 to -06
Refreshed the draft to the current date ("keep-alive"). Refreshed the draft to the current date ("keep-alive").
A.10. Changes from -04 to -05 A.11. Changes from -04 to -05
Discussed UUID usage in CBOR, and incorporated fixes proposed by Discussed UUID usage in CBOR, and incorporated fixes proposed by
Olivier Dubuisson, including fixes regarding OID nomenclature. Olivier Dubuisson, including fixes regarding OID nomenclature.
A.11. Changes from -03 to -04 A.12. Changes from -03 to -04
Changes occurred based on limited feedback, mainly centered around Changes occurred based on limited feedback, mainly centered around
the abstract and introduction, rather than substantive technical the abstract and introduction, rather than substantive technical
changes. These changes include: changes. These changes include:
* Changed the title so that it is about tags and techniques. * Changed the title so that it is about tags and techniques.
* Rewrote the abstract to describe the content more accurately, and * Rewrote the abstract to describe the content more accurately, and
to point out that no changes to the wire protocol are being to point out that no changes to the wire protocol are being
proposed. proposed.
skipping to change at page 15, line 22 skipping to change at page 16, line 46
of ASN.1. of ASN.1.
* Rewrote the introduction to be more about the present text. * Rewrote the introduction to be more about the present text.
* Proposed a concise OID arc. * Proposed a concise OID arc.
* Provided binary regular expression forms for OID validation. * Provided binary regular expression forms for OID validation.
* Updated IANA registration tables. * Updated IANA registration tables.
A.12. Changes from -02 to -03 A.13. Changes from -02 to -03
Many significant changes occurred in this version. These changes Many significant changes occurred in this version. These changes
include: include:
* Expanded the draft scope to be a comprehensive CBOR update. * Expanded the draft scope to be a comprehensive CBOR update.
* Added OID-related sections: OID Enumerations, OID Maps and Arrays, * Added OID-related sections: OID Enumerations, OID Maps and Arrays,
and Applications and Examples of OIDs. and Applications and Examples of OIDs.
* Added Tag 36 update (binary MIME, better definitions). * Added Tag 36 update (binary MIME, better definitions).
skipping to change at page 15, line 45 skipping to change at page 17, line 21
and Regular Expressions (tag 35). and Regular Expressions (tag 35).
* Added technique for representing sets and multisets. * Added technique for representing sets and multisets.
* Added references and fixed typos. * Added references and fixed typos.
Acknowledgments Acknowledgments
Sean Leonard started the work on this document in 2014 with an Sean Leonard started the work on this document in 2014 with an
elaborate proposal. Jim Schaad provided a significant review of this elaborate proposal. Jim Schaad provided a significant review of this
document. document. Rob Wilton's IESG review prompted us to provide preferred
serialization considerations.
Contributors Contributors
Sean Leonard Sean Leonard
Penango, Inc. Penango, Inc.
5900 Wilshire Boulevard 5900 Wilshire Boulevard
21st Floor 21st Floor
Los Angeles, CA, 90036 Los Angeles, CA, 90036
United States of America United States of America
Email: dev+ietf@seantek.com Email: dev+ietf@seantek.com
URI: http://www.penango.com/
Author's Address Author's Address
Carsten Bormann Carsten Bormann
Universität Bremen TZI Universität Bremen TZI
Postfach 330440 Postfach 330440
D-28359 Bremen D-28359 Bremen
Germany Germany
Phone: +49-421-218-63921 Phone: +49-421-218-63921
 End of changes. 38 change blocks. 
71 lines changed or deleted 152 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/