| < draft-ietf-cbor-tags-oid-05.txt | draft-ietf-cbor-tags-oid-08.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 19 February 2021 | Intended status: Standards Track 21 May 2021 | |||
| Expires: 23 August 2021 | Expires: 22 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-05 | draft-ietf-cbor-tags-oid-08 | |||
| 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 23 August 2021. | This Internet-Draft will expire on 22 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 | |||
| 2. Object Identifiers . . . . . . . . . . . . . . . . . . . . . 3 | 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
| 3. Basic Examples . . . . . . . . . . . . . . . . . . . . . . . 5 | 2. Object Identifiers . . . . . . . . . . . . . . . . . . . . . 4 | |||
| 4. Tag Factoring with Arrays and Maps . . . . . . . . . . . . . 7 | 2.1. Requirements on the byte string being tagged . . . . . . 5 | |||
| 5. CDDL Control Operators . . . . . . . . . . . . . . . . . . . 9 | 2.2. Preferred Serialization Considerations . . . . . . . . . 6 | |||
| 6. CDDL typenames . . . . . . . . . . . . . . . . . . . . . . . 10 | 2.3. Discussion . . . . . . . . . . . . . . . . . . . . . . . 6 | |||
| 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 | 3. Basic Examples . . . . . . . . . . . . . . . . . . . . . . . 7 | |||
| 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 | 3.1. Encoding of the SHA-256 OID . . . . . . . . . . . . . . . 7 | |||
| 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 | 3.2. Encoding of a MIB Relative OID . . . . . . . . . . . . . 7 | |||
| 9.1. Normative References . . . . . . . . . . . . . . . . . . 12 | 4. Tag Factoring with Arrays and Maps . . . . . . . . . . . . . 8 | |||
| 9.2. Informative References . . . . . . . . . . . . . . . . . 13 | 4.1. Preferred Serialization Considerations . . . . . . . . . 8 | |||
| Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 13 | 4.2. Tag Factoring Example: X.500 Distinguished Name . . . . . 9 | |||
| Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 15 | 5. CDDL Control Operators . . . . . . . . . . . . . . . . . . . 10 | |||
| Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 15 | 6. CDDL typenames . . . . . . . . . . . . . . . . . . . . . . . 11 | |||
| Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16 | 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 | |||
| 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, | |||
| [X.660]), which many IETF protocols carry. The ASN.1 Basic Encoding | [X.660]), which many IETF protocols carry. The ASN.1 Basic Encoding | |||
| Rules (BER, [X.690]) specify binary encodings of both (absolute) | Rules (BER, [X.690]) specify binary encodings of both (absolute) | |||
| object identifiers and relative object identifiers. The contents of | object identifiers and relative object identifiers. The contents of | |||
| these encodings (the "value" part of BER's type-length-value | these encodings (the "value" part of BER's type-length-value | |||
| structure) can be carried in a CBOR byte string. This document | structure) can be carried in a CBOR byte string. This document | |||
| defines two CBOR tags that cover the two kinds of ASN.1 object | defines two CBOR tags that cover the two kinds of ASN.1 object | |||
| identifiers encoded in this way. The tags can also be applied to | identifiers encoded in this way, and a third one to enable a common | |||
| arrays and maps to efficiently tag all elements of an array or all | optimization. The tags can also be applied to arrays and maps to | |||
| keys of a map. It is intended as the reference document for the IANA | efficiently tag all elements of an array or all keys of a map. It is | |||
| registration of the tags so defined. | intended as the 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", | 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]. | verb "to tag (something)" is used to express the construction of a | |||
| CBOR tag with the object (something) as the tag content and a tag | ||||
| number indicated elsewhere in the sentence (for instance in a "with" | ||||
| clause, or by the shorthand "an NNN tag" for "a tag with tag number | ||||
| NNN"). The 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 | |||
| skipping to change at page 4, line 11 ¶ | skipping to change at page 4, line 48 ¶ | |||
| 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 number TBD111: used to tag a byte string as the [X.690] encoding | |||
| object identifier (simply "object identifier" or "OID"). | of an absolute object identifier (simply "object identifier" or | |||
| "OID"). | ||||
| Tag TBD110: tags a byte string as the [X.690] encoding of a relative | Tag number TBD110: used to tag a byte string as the [X.690] encoding | |||
| object identifier (also "relative OID"). Since the encoding of each | of a relative object identifier (also "relative OID"). Since the | |||
| number is the same as for [RFC6256] Self-Delimiting Numeric Values | encoding of each number is the same as for [RFC6256] Self-Delimiting | |||
| (SDNVs), this tag can also be used for tagging a byte string that | Numeric Values (SDNVs), this tag can also be used for tagging a byte | |||
| contains a sequence of zero or more SDNVs. | string that 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 with TBD111, TBD110, or | |||
| TBD112 MUST be a syntactically valid BER representation of an object | TBD112 MUST be syntactically valid contents (the value part) for a | |||
| identifier: A concatenation of zero or more SDNV values, where each | BER representation of an object identifier (Sections 8.19, 8.20, and | |||
| SDNV value is a sequence of one or more bytes that all have their | 8.20 of [X.690], respectively): A concatenation of zero or more SDNV | |||
| most significant bit set, except for the last byte, where it is | values, where each SDNV value is a sequence of one or more bytes that | |||
| unset. Also, the first byte of each SDNV cannot be a leading zero in | all have their most significant bit set, except for the last byte, | |||
| SDNV's base-128 arithmetic, so it cannot take the value 0x80 (bullet | where it is unset. Also, the first byte of each SDNV cannot be a | |||
| (c) in Section 8.1.2.4.2 of [X.690]). | leading zero in SDNV's base-128 arithmetic, so it cannot take the | |||
| value 0x80 (bullet (c) in Section 8.1.2.4.2 of [X.690]). | ||||
| In other words: | In other words: | |||
| * the byte string's first byte, and any byte that follows a byte | * the byte string's first byte, and any byte that follows a byte | |||
| that has the most significant bit unset, MUST NOT be 0x80 (this | that has the most significant bit unset, MUST NOT be 0x80 (this | |||
| requirement requires expressing the integer values in their | requirement requires expressing the integer values in their | |||
| shortest form, with no leading zeroes) | shortest form, with no leading zeroes) | |||
| * the byte string's last byte MUST NOT have the most significant bit | * the byte string's last byte MUST NOT have the most significant bit | |||
| set (this requirement excludes an incomplete final integer value) | set (this requirement excludes an incomplete final integer value) | |||
| skipping to change at page 5, line 30 ¶ | skipping to change at page 6, line 25 ¶ | |||
| 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 8, line 6 ¶ | |||
| 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 | The tag content of OID tags can be byte strings (as discussed above), | |||
| arrays and maps. The idea in the latter case is that the tag is | but also CBOR arrays and maps. The idea in the latter case is that | |||
| factored out from each individual item in the container; the tag is | the tag construct is factored out from each individual item in the | |||
| placed on the array or map instead. | container; the tag is placed on the array or map instead. | |||
| When an OID tag is applied to an array, it means that the respective | When the tag content of an OID tag is an array, this means that the | |||
| tag is imputed to all elements of the array that are byte strings, | respective tag is imputed to all elements of the array that are byte | |||
| arrays, or maps. (There is no effect on other elements, including | strings, arrays, or maps. (There is no effect on other elements, | |||
| text strings or tags.) For example, when an array is tagged with | including text strings or tags.) For example, when the tag content | |||
| TBD111, every array element that is a byte string is an OID, and | of a TBD111 tag is an array, every array element that is a byte | |||
| every element that is an array or map is in turn treated as discussed | string is an OID, and every element that is an array or map is in | |||
| here. | turn treated as discussed here. | |||
| When an OID tag is applied to a map, it means that the respective tag | When the tag content of an OID tag is a map, this means that a tag | |||
| is imputed to all keys in the map that are byte strings, arrays, or | with the same tag number is imputed to all keys in the map that are | |||
| maps; again, there is no effect on keys of other major types. Note | byte strings, arrays, or maps; again, there is no effect on keys of | |||
| that there is also no effect on the values in the map. | other major types. Note 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 number TBD111 is used, some OIDs | ||||
| enclosed in the tag may be encoded in a shorter way by using tag | ||||
| number 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 30 ¶ | |||
| | | 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 tag numbers 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: New Tag Numbers | |||
| 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 -04 to -05 | 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 | ||||
| explain validity of enclosed byte string. | ||||
| A.3. Changes from -04 to -05 | ||||
| * Update acknowledgements, contributor list, and author list | * Update acknowledgements, contributor list, and author list | |||
| A.2. 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.3. 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.4. 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.5. Changes from -00 to -01 | A.7. Changes from -00 to -01 | |||
| Clean up OID tag factoring. | Clean up OID tag factoring. | |||
| A.6. 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.7. 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.8. 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.9. 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.10. 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 16 ¶ | 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.11. 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 39 ¶ | 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. 43 change blocks. | ||||
| 103 lines changed or deleted | 199 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/ | ||||