Internet-Draft | COTE | July 2022 |
Rundgren | Expires 20 January 2023 | [Page] |
This document describes a CBOR tag for providing type information to CBOR data. Unlike the native CBOR tagging scheme which depends on the IANA registry, this specification supports arbitrary typing schemes, including using URLs.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 20 January 2023.¶
Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.¶
This specification introduces a method for augmenting data expressed in the CBOR [RFC8949] notation, with a universal type identifier mechanism.¶
The primary purpose is to enable developers defining community- or application-specific type identifiers without having to go through an IANA registration process. Although the scheme imposes no restrictions on type identifiers (beyond being valid CBOR data items), using URLs should due to their ubiquity be a candidate for CBOR based standards.¶
Since the type identifier scheme is supposed to be an integral part of CBOR data items, compliant items may also be embedded in other CBOR and non-CBOR constructs, as well as stored in databases without any additional information.¶
If applied to top level items, the type identifier scheme may also reduce the need for application specific media types. In many cases "application/cbor" should suffice.¶
In this document the term CBOR "object" is used interchangeably with the CBOR [RFC8949] "data item".¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
This specification builds on the CBOR [RFC8949] tag feature (major type 6), by defining a fixed tag with the preliminary decimal value of 211.¶
This tag MUST in turn enclose a CBOR array with two elements, where the first element contains an object identifier, while the second holds the object data itself. Illustrated in CBOR diagnostic notation (section 8 of [RFC8949]) this becomes:¶
211([Object Identifier, Object])¶
Both arguments may be any valid CBOR object.¶
Note that real-world usages will typically impose constraints like requiring object identifiers to be expressed as https URLs etc.¶
Consider the following sample:¶
211(["https://example.com/myobject", { 1: "data", 2: "more data" }])¶
Converted to CBOR expressed in hexadecimal notation the following is to be expected:¶
D8 D3 # tag(211) 82 # array(2) 78 1C # text(28) 68747470733A2F2F6578616D706C652E636F6D2F6D796F626A656374 # "https://example.com/myobject" A2 # map(2) 01 # unsigned(1) 64 # text(4) 64617461 # "data" 02 # unsigned(2) 69 # text(9) 6D6F72652064617461 # "more data"¶
In the registry [IANA.cbor-tags], IANA is requested to allocate the tag defined in Table 1.¶
Tag | Data Item | Semantics | Reference |
---|---|---|---|
211 | array: [id, object] | Object identifier | draft-rundgren-cote |
This specification inherits all the security considerations of CBOR [RFC8949].¶
URL-based type identifiers MUST NOT be used for automatically downloading possible CBOR schemas to CBOR processors, since this introduces potential vulnerabilities. A RECOMMENDED way deploying URL-based type identifiers is as hyper-links to human-readable information gathered through Web browsers.¶
The availability of type information does in no way limit the need for input data validation.¶
For signed CBOR objects, it is RECOMMENDED to include the type identifier extension in the signature calculation as well. The same considerations apply to encryption using AEAD algorithms.¶
People who have contributed directly and indirectly with valuable input to this specification include TBD¶
[[ This section to be removed by the RFC Editor before publication as an RFC ]]¶
Version 00:¶