This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
in Bell Labs, Unix Programmer's Manual, First Edition: File Formats
venue:
mail: cbor@ietf.org
github: cbor-wg/cbor-magic-number
--- abstract
This document defines an on-disk format for CBOR data items that
is friendly to common on-disk recognition systems such as the Unix file(1) command.
This document defines a stored ("file") format for CBOR data items that
is friendly to common file type recognition systems such as the Unix file(1) command.
--- middle
# Introduction
Since very early in computing, operating systems have sought ways to mark which files could be processed by which programs.
In Unix, everything is a stream of bytes (related to the TCP/IP
socket model, where all network connectivity also is a stream of
bytes); identifying the contents of a stream of bytes became a heuristic activity.
In Unix, everything is a stream of bytes; identifying the contents of a stream of bytes became a heuristic activity.
For instance, the Unix file(1) command, which has existed since 1973 {{file}}, has for decades been able to identify many file formats based upon the contents of the file.
Many systems (Linux, macOS, Windows) will select the correct application based upon the file contents, if the system can not determine it by other means.
For instance, in classical MacOS, a resource fork was maintained that includes media type ("MIME type") information and therefore ideally never needs to know anything about the file.
For instance, in classical MacOS, a resource fork was maintained
separately from the file data that included file type information;
this way, the OS ideally never needed to know anything about the file
data contents to determine the media type.
But, many other systems do this by file extensions.
Many other systems do this by file extensions.
Many common web servers derive the media-type information from file extensions.
Having a media type associated with the file is a better solution in
general.
When files become disconnected from their type information, such as when attempting to do forensics on a damaged system, then being able to identify a file type can become very important.
Having a media type associated with the file contents can avoid some
of the brittleness of this approach.
When files become disconnected from their type information, such as when attempting to do forensics on a damaged system, then being able to identify the type of information that is stored in file can become very important.
It is noted that in the media type registration template, a magic number is asked for, if available, as is a file extension.
A common way to identify the type of a file from its contents is to
place a "magic number" at the start of the file contents {{MAGIC}}.
It is noted that in the media type registration template {{-mediareg}}, a magic number is asked for, if available, as is a file extension.
A challenge for the file(1) program is often that it can be confused by the encoding vs the content.
For instance, an Android "apk" used to transfer and store an application may be identified as a ZIP file.
A challenge for the file(1) command is often that it can be confused by the encoding vs. the content.
For instance, an Android "apk" (as used to transfer and store an application) may be identified as a ZIP file.
Additionally, both OpenOffice and MSOffice files are ZIP files of XML files, and may also be identified as a ZIP file.
As CBOR becomes a more and more common encoding for a wide variety of artifacts, identifying them as just "CBOR" is probably not sufficient.
This document provides a way to encode a magic number into the beginning of a CBOR format file.
As a CBOR format may use a single CBOR data item or a CBOR sequence of
data items {{-seq}},
two possible methods of enveloping data are presented:a CBOR Protocol designer will specify one.
two possible methods of enveloping data are presented; a CBOR Protocol designer will specify one.
(A CBOR Protocol is a specification which uses CBOR as its encoding.)
A third method is also proposed by which this CBOR format prepended tag is used to identify non-CBOR files.
This third method has been placed in an appendix because it is not
about identifying media types containing CBOR-encoded data items.
This document also gives advice to designers of CBOR protocols on
This document also gives advice to designers of CBOR Protocols on
choosing one of these mechanisms for identifying their contents.
This advice is informative.
A third method is also proposed by which this CBOR format prepended tag is used to identify non-CBOR files.
This third method has been placed in {{headers}} because it is not
about identifying media types containing CBOR-encoded data items.
This includes a simple way to derive a magic number to content-formats
as defined by {{-coap}}, even if not in CBOR form.
Examples of CBOR Protocols currently under development include Concise
Software Identification Tags (CoSWID, {{?I-D.ietf-sacm-coswid}}) and
@@ -119,46 +143,55 @@ A major inspiration for this document is observing the disarray in certain
ASN.1 based systems where most files are PEM encoded; these are then all identified by the extension "pem", confusing public keys, private keys, certificate requests, and S/MIME content.
While the envelopes defined in this specification add information to how data conforming to CBOR Protocols are stored in files, there is no requirement that either type of envelope be transferred on the wire.
In addition to the on-disk identification aspects, there are some protocols which may benefit from having such a magic number on the wire if they are presently using a different (legacy) encoding scheme.
The presence of the identifiable magic sequence signals that CBOR is
being used as opposed to a legacy scheme.
In addition, for convenience, {{headers}} defines a simple way to
retroactively add a magic number to content-formats as defined by
{{-coap}}, even if not in CBOR form.
However, there are some protocols which may benefit from having such a magic number on the wire if they are presently using a different (legacy) encoding scheme.
The presence of the identifiable magic sequence can be used to signal
that a CBOR Protocol is being used as opposed to a legacy scheme.
## Terminology
Byte is a synonym for octet.
The term "byte string" refers to the data item defined in {{STD94}}.
The term "file" is understood to stand in a general way for a stored
representation that is somewhat detached from the original context of
usage of that representation; its usage in this document encompasses
similar units of storage that may have different identification
schemes such as partitions or media blocks.
The term "diagnostic notation" refers to the human-readable notation
for CBOR data items defined in {{Section 8 of STD94}} and {{Section G of RFC8610}}.
The term CDDL (Concise Data Definition Language) refers to the
language defined in {{RFC8610}}.
The function TN(ct) is defined in {{ct-tags}}.
## Requirements for a Magic Number
A magic number is ideally a fingerprint that is unique to a CBOR protocol, present in the first few (small multiple of 4) bytes of the file,
A magic number is ideally a fingerprint that is unique to a specific CBOR protocol, present in the first few (small multiple of 4) bytes of the file,
which does not change when the contents change, and does not depend upon the length of the file.
Less ideal solutions have a pattern that needs to be matched, but in which some bytes need to be ignored.
While the Unix file(1) command can be told to ignore certain bytes, this can lead to ambiguities.
# Protocol
This Section presents two enveloping methods. Which one is to be used is up to the CBOR Protocol designer to determine.
This Section presents two enveloping methods.
Both use CBOR Tags in a way that results in a deterministic first 8 to 12 bytes.
Which one is to be used
is up to the CBOR Protocol designer to determine; see {{advice}} for
some guidance.[^appendix]
[^appendix]: We are preparing a move of Section 3 "Advice..." to the Appendix;
this is going to be the necessary reference.
## The CBOR Protocol Specific Tag
## The CBOR Protocol Specific Tag {#spectag}
In both enveloping methods,
CBOR Protocol designers need to obtain a CBOR tag for each kind of object that they might store on disk.
CBOR Protocol designers need to obtain a CBOR tag for each kind of object that they might store in files.
As there are more than 4 billion available 4-byte tags, there should be little issue in allocating a few to each available CBOR Protocol.
The IANA policy for 4-byte CBOR Tags is First Come First Served, so all that is required is an email to IANA, having filled in the small template provided in {{Section 9.2 of STD94}}.
The IANA policy for 4-byte CBOR Tags is First Come First Served, so all that is required is a simple interaction (e.g., via web or email) with IANA, having filled in the small template provided in {{Section 9.2 of STD94}}.
In the template, it is suggested to include a reference to this
specification (RFC XXXX) alongside the Description of
semantics. [^XXXX]
@@ -167,24 +200,28 @@ semantics. [^XXXX]
XXXX" with the RFC number of the present specification and remove
this note.)
This tag needs to be allocated by the author of the CBOR Protocol.
Allocation of the CBOR tag needs to be initiated by the designer of the CBOR
Protocol, who can provide a proposed tag number.
In order to be in the four-byte range, and so that there are no
leading zeros, the value needs to be in the range 0x01000000 (decimal
16777216) to 0xFFFFFFFF (decimal 4294967295).
leading zero bytes in the four-byte encoding of the tag number, the
value needs to be in the range 0x01000000 (decimal
16777216) to 0xFFFFFFFF (decimal 4294967295) inclusive.
It is further suggested to avoid values that have an embedded zero byte in
the four bytes of their binary representation (such as 0x12003456), as
these may confuse implementations that treat the magic number as a C string.
The use of a sequence of four US-ASCII codes which are mnemonic to the protocol is encouraged, but not required.
The use of a sequence of four US-ASCII {{-ascii}} codes which are mnemonic to the
protocol is encouraged, but not required (there may be reasons to
encode other information into the tag; see {{ct-tags}} for an example).
For instance, {{openswan}} uses "OPSN" which translates to the tag
number 1330664270 registered for it.
For CBOR data items that form a representation that is
described by a CoAP Content-Format Number ({{Section 12.3 of -coap}},
a tag number has already been allocated in {{iana-ct-tags}} (see {{ct-tags}}
a tag number has pro-actively been allocated in {{iana-ct-tags}} (see {{ct-tags}}
for details and examples).
## Enveloping Method: CBOR Tag Wrapped {#wrapped}
@@ -195,31 +232,44 @@ This data item is enveloped into two nested tags:
The outer tag is a Self-described CBOR tag, 55799, as
described in {{Section 3.4.6 of STD94}}.
The tag content of that tag is a second CBOR Tag that has been allocated to describe the specific Protocol involved, as described above.
This method wraps the CBOR value as tags usually do.
Applications that need to send the CBOR value across a constrained link may wish to remove the two tags if the use is implicitly understood.
A CBOR Protocol specification may specify the use of two tags only for
specific cases. For instance, it might use them when storing the
representation in a local file or for Web access, but not when using them
in protocol messages that already provide the necessary context.
The tag content of the outer tag is a second CBOR tag whose tag number has
been allocated to describe the specific Protocol involved, as
discussed in {{spectag}}.
The tag content of this inner tag is the single CBOR data item.
This method wraps the CBOR data item as CBOR tags usually do.
Applications that need to send the stored CBOR data item across a
constrained network may wish to remove the two tags if the type is
understood from the protocol context, e.g., from a CoAP Content-Format
Option ({{Section 5.10.3 of RFC7252}}).
A CBOR Protocol specification may therefore pick the specific cases
where the CBOR Tag Wrapped enveloping method is to be used.
For instance, it might specify its use for storing the representation
in a local file or for Web access, but not within protocol messages that
already provide the necessary context.
### Example {#tag-wrap-example}
To construct an example without registering a new tag, we use the technique described in {{ct-tags}} to translate the Content-Format number registered for `application/senml+cbor` (as per Registry {{content-formats (Content-Formats)<IANA.core-parameters}} of {{IANA.core-parameters}}), the number 112, into the tag 1668546560+112 = 1668546672.
To construct an example without registering a new tag, we use the
Content-Format number registered in {{-senml}} for
`application/senml+cbor`(as per Registry {{content-formats
(Content-Formats)<IANA.core-parameters}} of {{IANA.core-parameters}}),
the number 112.
Using the technique described in {{ct-tags}}, this translates into the
tag TN(112) = 1668546929.
With this tag, the SenML-CBOR pack `[{0: "current", 6: 3, 2: 1.5}]` would be enveloped as (in diagnostic notation):
~~~ cbor-diag
55799(1668546672([{0: "current", 6: 3, 2: 1.5}]))
55799(1668546929([{0: "current", 6: 3, 2: 1.5}]))
~~~
Or in hex:
~~~~ cbor-pretty
d9 d9f7 # tag(55799)
da 63740070# tag(1668546672)
da 63740171# tag(1668546929)
81 # array(1)
a3 # map(3)
00 # unsigned(0)
@@ -231,7 +281,7 @@ d9 d9f7 # tag(55799)
f9 3e00 # primitive(15872)
~~~~
At the representation level, the unique fingerprint for `application/senml+cbor` is composed of the 8 bytes d9d9f7da63740070 hex, after which the unadorned CBOR data (81... for the SenML data) is appended.
At the representation level, the unique fingerprint for `application/senml+cbor` is composed of the 8 bytes d9d9f7da63740171 hex, after which the unadorned CBOR data (81... for the SenML data) is appended.
@@ -249,7 +299,7 @@ The total length of the label is 12 bytes.
2. The inner tag is a CBOR tag, from the First Come First Served space, that uniquely identifies the CBOR Protocol.
As with CBOR Tag Wrapped, the use of a four-byte tag is encouraged that encodes without zero bytes.
3. The tag content is a three byte CBOR byte string containing
0x42\_4F\_52 ('BOR' in diagnostic notation).
0x42\_4f\_52 ('BOR' in diagnostic notation).
The outer tag in the label identifies the file as being a CBOR Sequence, and does so with all
the desirable properties explained in {{Section 3.4.6 of STD94}}.
@@ -269,15 +319,58 @@ Should this file be reviewed by a human (directly in an
editor, or in a hexdump display), it will include the ASCII characters "CBOR" prominently.
This value is also included simply because the inner nested tag needs to tag something.
# Advice to Protocol Designer
### Example {#tag-seq-example}
To construct an example without registering a new tag, we use the
Content-Format number registered in {{-new-block}} for
`application/missing-blocks+cbor-seq`(as per Registry
{{content-formats (Content-Formats)<IANA.core-parameters}} of
{{IANA.core-parameters}}), the number 272.
Using the technique described in {{ct-tags}}, this translates into the
tag TN(272) = 1668547090.
This is a somewhat contrived example, as this is not a media type that
is likely to be committed to storage.
Nonetheless, with this tag, missing blocks list `0, 8, 15` would be
enveloped as (in diagnostic notation):
~~~ cbor-diag
55800(1668547090('BOR')),
0,
8,
15
~~~
Or in hex:
~~~~ cbor-pretty
# CBOR sequence with 4 elements
d9 d9f8 # tag(55800)
da 63740212 # tag(1668547090)
43 # bytes(3)
424f52 # "BOR"
00 # unsigned(0)
08 # unsigned(8)
0f # unsigned(15)
~~~~
At the representation level, the unique fingerprint for
`application/missing-blocks+cbor-seq`is composed of the 8 bytes
d9d9f8da63740212 hex, after which the unadorned CBOR sequence
(00... for the missing block list given) is appended.
# Advice to Protocol Designer {#advice}
This document introduces a choice between wrapping a single CBOR data item into a (pair of) identifying CBOR tags, or prepending an identifying encoded CBOR data item (which in turn contains a pair of identifying CBOR tags) to a CBOR Sequence (which might be single data item).
Which should a protocol designer use?
In this discussion, one assumes that there is an object stored in a file, perhaps specified by a system operator in a configuration file.
For example: a private key used in COSE operations, a public key/certificate in C509 ({{?I-D.ietf-cose-cbor-encoded-cert}}) or CBOR format, a recorded sensor reading stored for later transmission, or a COVID vaccination certificate that needs to be displayed in QR code form.
For example: a private key used in COSE operations, a public key/certificate in C509 ({{?I-D.ietf-cose-cbor-encoded-cert}}) or CBOR format, a recorded sensor reading stored for later transmission, or a COVID-19 vaccination certificate that needs to be displayed in QR code form.
Both the Labeled CBOR Sequence and the wrapped tag can be trivially removed by an application before sending the CBOR content out on the wire.
@@ -293,9 +386,9 @@ As an example of where there was a problem with previous security systems, "PEM"
The PKCS1 format {{-pkcs1}} could also contain a private key object followed by a one or more certificate objects: but only when in PEM format.
Annoyingly, when in binary DER format ({{X.690}}, which like CBOR is self-delimiting), concatenation of certificates was not compatible with most programs as they did not expect to read more than one item in the file.
The use of CBOR Tag Wrapped format is easier to retrofit to an existing format with existing and unchangeable on-disk format for a single CBOR data item.
The use of CBOR Tag Wrapped format is easier to retrofit to an existing format with existing and unchangeable stored format for a single CBOR data item.
This new sequence of tags is expected to be trivially ignored by many
existing programs when reading CBOR from disk, even if the program only
existing programs when reading CBOR from files or similar units of storage, even if the program only
supports decoding a single data item (and not a CBOR sequence).
But, a naive program might also then transmit the additional tags across the network.
Removing the CBOR Tag Wrapped format requires knowledge of the two tags involved.
@@ -313,9 +406,9 @@ Here are some considerations in the form of survey questions:
## Is the on-wire format new?
If the on-wire format is new, then it could be specified with the CBOR Tag Wrapped format if the extra eight bytes are not a problem.
The disk format is then identical to the on-wire format.
The stored format is then identical to the on-wire format.
If the eight bytes are a problem on the wire (and they often are if CBOR is being considered), then the Labeled CBOR Sequence format should be adopted for on-disk storage.
If the eight bytes are a problem on the wire (and they often are if CBOR is being considered), then the Labeled CBOR Sequence format should be adopted for the stored format.
## Can many items be trivially concatenated?
@@ -324,7 +417,7 @@ If the programs that read the contents of the file already expect to process all
The program involved may throw errors or warnings on the Labeled CBOR Sequence if they have not yet been updated, but this may not be a problem.
There are situations where multiple objects may be concatenated into a single file.
If each object is preceded by a Labeled CBOR Sequence label then there may be
If each object is preceded by a Labeled CBOR Sequence label then there may be
multiple such labels in the file.
<!-- ???If it is, then consideration should be given to CBOR Tag Wrapped instead.??? -->
@@ -349,15 +442,29 @@ If only one item is ever expected in the file, the use of Labeled CBOR Sequence
## Are there tags at the start?
If the Protocol expects to use other tags values at the top-level, then the use
of the tag wrapped format may be easier to explain in the protocol description.
If the Protocol expects to use other tags at its top-level, then the
use of the CBOR Tag Wrapped format may be easy to explain at the same
place in the protocol description.
# Security Considerations
This document provides a way to identify CBOR Protocol objects.
Clearly identifying CBOR contents on disk may have a variety of impacts.
The most obvious is that it may allow malware to identify interesting objects on disk, and then exfiltrate or corrupt them.
Clearly identifying CBOR contents in files may have a variety of impacts.
The most obvious is that it may allow malware to identify interesting
stored objects, and then exfiltrate or corrupt them.
Protective applications (that check data) cannot rely on the
applications they try to protect (that use the data) to make
exactly the same decisions in recognizing file formats.
(This is an instance of a check vs. use issue.)
For example, end-point assessment technologies should not solely rely
on the labeling approaches described in this document to decide
whether to inspect a given file.
Similarly, depending on operating systems configurations and related
properties of the execution environment the labeling might influence
the default application used to process a file in a way that may not
be predicted by a protective application.
# IANA Considerations
@@ -424,16 +531,17 @@ Semantics:
## CBOR Tags for CoAP Content-Format Numbers {#iana-ct-tags}
IANA is requested to allocate the
tag numbers 1668546560 (0x63740000) to
1668612095 (0x6374FFFF) as follows:
tag numbers 1668546817 (0x63740101) to
1668612095 (0x6374ffff) as follows:
{: newline="true"}
Data Item:
: byte string
<!-- Er, hmm. -->
Semantics:
: for each tag number NNNNNNNN, the representation of content-format NNNNNNNN-1668546560
: the representation of content-format ct < 65025 is indicated by
tag number TN(ct) = 0x63470101 + (ct / 255) * 256 + ct % 255
Reference:
: RFCthis
@@ -449,14 +557,34 @@ which is a short 16-bit unsigned integer that identifies a specific
content type (media type plus optionally parameters), optionally
together with a content encoding.
Outside of a transfer protocol that indicates the Content-Format for a representation, it may be necessary to identify the Content-Format of the representation when it is on disk, in firmware, or when debugging.
Outside of a transfer protocol that indicates the Content-Format for a representation, it may be necessary to identify the Content-Format of the representation when it is stored in a file, in firmware, or when debugging.
This specification allocates CBOR tag numbers 1668546560 (0x63740000) to
This specification allocates CBOR tag numbers 1668546817 (0x63740101) to
1668612095 (0x6374FFFF) for the tagging of representations of specific
content formats.
The tag content tagged with tag number NNNNNNNN (in above range) is a byte
string that is to be interpreted as a representation of the content
format NNNNNNNN-1668546560.
Using tags from this range, a byte string that is to be interpreted as
a representation of Content-Format number `ct`, with ct < 65025
(255*255), can be identified by enclosing it in a tag with tag number
(where `+`, `*`, `/` and `%` stand for integer addition,
multiplication, division and remainder as in the programming language
C {{C}}.)
{:aside}
> This formula avoids the use of zero bytes in the representation of
the tag number.
>
> Note that no tag numbers are assigned for Content-Format numbers in
the range 65025 {{{≤}}} ct {{{≤}}} 65535.
(This range is in the range reserved by {{Section 12.3 of -coap}} for
experimental use.
The overlap of 25 code points between this experimental range with the
range this appendix defines tag numbers for can be used for
experiments that want to employ a tag number.)
Exceptionally, when used immediately as tag content of one of the tags
55799, 55800, or 55801, the tag content is as follows:
@@ -482,13 +610,13 @@ Registry {{content-formats (Content-Formats)<IANA.core-parameters}} of {{IANA.co
* As discussed in {{tag-wrap-example}}, Content-Format 112 stands for
media type application/senml+cbor (no parameters).
The corresponding tag number is 1668546672 (i.e., 1668546560+112).
The corresponding tag number is TN(112) = 1668546929.
So the following CDDL snippet can be used to identify
application/senml+cbor representations:
~~~~ cddl
senml-cbor = #6.1668546672(bstr)
senml-cbor = #6.1668546929(bstr)
~~~~
Note that a byte string is used as the type of the tag content, because a
@@ -498,14 +626,14 @@ Registry {{content-formats (Content-Formats)<IANA.core-parameters}} of {{IANA.co
application/missing-blocks+cbor-seq, a CBOR sequence
{{-new-block}}.
The corresponding tag number is 1668546832 (i.e., 1668546560+272).
The corresponding tag number is TN(272) = 1668547090.
So the following CDDL snippet can be used to identify
application/missing-blocks+cbor-seq representations as embedded in a
CBOR byte string:
~~~~ cddl
missing-blocks = #6.1668546832(bstr)
missing-blocks = #6.1668547090(bstr)
~~~~
# Example from Openswan {#openswan}
@@ -514,18 +642,18 @@ The Openswan IPsec project has a daemon ("pluto"), and two control programs ("ad
They communicate via a Unix-domain socket, over which a C-structure containing pointers to strings is serialized using a bespoke mechanism.
This is normally not a problem as the structure is compiled by the same compiler; but when there are upgrades it is possible for the daemon and the control programs to get out of sync by the bespoke serialization.
As a result, there are extra compensations to deal with shutting the daemon down.
During testing it is sometimes the case that upgrades are backed out.
During testing, it is sometimes the case that upgrades are backed out.
In addition, when doing unit testing, the easiest way to load policy is to use the
normal policy reading process, but that is not normally loaded in the daemon.
Instead the IPC that is normally sent across the wire is compiled/serialized and placed in a file.
Instead, the IPC that is normally sent across the wire is compiled/serialized and placed in a file.
The above magic number is included in the file, and also on the IPC in order to distinguish the "shutdown" command CBOR operation.
In order to reduce the problems due to serialization, the serialization is being changed to CBOR.
Additionally, this change allows the IPC to be described by CDDL, and for any language that encode to CBOR can be used.
IANA has allocated the tag 1330664270, or 0x4f\_50\_53\_4e for this purpose.
As a result, each file and each IPC is prefixed with a CBOR TAG Sequence.
As a result, each file and each IPC is prefixed with a CBOR Tag Sequence.
In diagnostic notation:
@@ -536,10 +664,10 @@ In diagnostic notation:
Or in hex:
~~~~ cbor-pretty
D9 D9F8# tag(55800)
DA 4F50534E# tag(1330664270)
d9 d9f8# tag(55800)
da 4f50534e# tag(1330664270)
43 # bytes(3)
424F52# "BOR"
424f52# "BOR"
~~~~
# Using CBOR Labels for non-CBOR data {#headers}
@@ -578,34 +706,33 @@ CBOR representation of the header.
This allows the application to trivially remove the header item with
the two nested tags and the byte string.
Should this file be reviewed by a human (directly in an
editor, or in a hexdump display), it will include the ASCII characters
"CBOR"prominently to indicate the nature of the header.
This value is also included simply because the two tags need to tag something.
As with the Labeled CBOR Sequence {#sequences}, this choice of the tag
content places the ASCII characters "CBOR" prominently into the
header.
## Content-Format Tag Examples {#header-ct-examples}
Registry {{content-formats (Content-Formats)<IANA.core-parameters}} of {{IANA.core-parameters}} defines content formats that can be used as examples:
* Content-Format 432 stands for media type application/td+json (no
parameters).
The corresponding tag number is 1668546992 (i.e., 1668546560+432).
The corresponding tag number is TN(432) = 1668547250.
So the following CDDL snippet can be used to identify a CBOR-Labeled non-CBOR data for application/td+json representations:
~~~~ cddl
td-json-header = #6.55801(#6.1668546992('BOR'))
td-json-header = #6.55801(#6.1668547250('BOR'))
~~~~
* Content-Format 11050 stands for media type application/json in
deflate content-coding.
The corresponding tag number is 1668557610 (i.e., 1668546560+11050).
The corresponding tag number is TN(11050) = 1668557910.
So the following CDDL snippet can be used to identify a CBOR-Labeled non-CBOR data for application/json representations compressed in deflate content-coding: