<?xml version='1.0' encoding='utf-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="std" consensus="true" docName="draft-ietf-cbor-file-magic-12" indexInclude="true" ipr="trust200902" number="9277" prepTime="2022-08-30T17:57:43" scripts="Common,Latin" sortRefs="true" submissionType="IETF" symRefs="true" tocDepth="3" tocInclude="true">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-cbor-file-magic-12" rel="prev"/>
  <link href="https://dx.doi.org/10.17487/rfc9277" rel="alternate"/>
  <link href="urn:issn:2070-1721" rel="alternate"/>
  <front>
    <title abbrev="cbor-file-magic">On Stable Storage for Items in Concise Binary Object Representation (CBOR)</title>
    <seriesInfo name="RFC" value="9277" stream="IETF"/>
    <author initials="M." surname="Richardson" fullname="Michael Richardson">
      <organization showOnFrontPage="true">Sandelman Software Works</organization>
      <address>
        <email>mcr+ietf@sandelman.ca</email>
      </address>
    </author>
    <author initials="C." surname="Bormann" fullname="Carsten Bormann">
      <organization showOnFrontPage="true">Universität Bremen TZI</organization>
      <address>
        <postal>
          <street>Postfach 330440</street>
          <city>D-28359 Bremen</city>
          <country>Germany</country>
        </postal>
        <phone>+49-421-218-63921</phone>
        <email>cabo@tzi.org</email>
      </address>
    </author>
    <date month="08" year="2022"/>
    <area>art</area>
    <workgroup>cbor</workgroup>
    <keyword>magic number</keyword>
    <keyword>file identification</keyword>
    <abstract pn="section-abstract">
      <t indent="0" pn="section-abstract-1">This document defines a stored ("file") format for Concise Binary
   Object Representation (CBOR) data items
that is friendly to common systems that recognize file types, such 
as the Unix file(1) command.</t>
    </abstract>
    <boilerplate>
      <section anchor="status-of-memo" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.1">
        <name slugifiedName="name-status-of-this-memo">Status of This Memo</name>
        <t indent="0" pn="section-boilerplate.1-1">
            This is an Internet Standards Track document.
        </t>
        <t indent="0" pn="section-boilerplate.1-2">
            This document is a product of the Internet Engineering Task Force
            (IETF).  It represents the consensus of the IETF community.  It has
            received public review and has been approved for publication by
            the Internet Engineering Steering Group (IESG).  Further
            information on Internet Standards is available in Section 2 of 
            RFC 7841.
        </t>
        <t indent="0" pn="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be obtained at
            <eref target="https://www.rfc-editor.org/info/rfc9277" brackets="none"/>.
        </t>
      </section>
      <section anchor="copyright" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.2">
        <name slugifiedName="name-copyright-notice">Copyright Notice</name>
        <t indent="0" pn="section-boilerplate.2-1">
            Copyright (c) 2022 IETF Trust and the persons identified as the
            document authors. All rights reserved.
        </t>
        <t indent="0" pn="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<eref target="https://trustee.ietf.org/license-info" brackets="none"/>) 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. Code Components extracted from this
            document must include Revised BSD License text as described in
            Section 4.e of the Trust Legal Provisions and are provided without
            warranty as described in the Revised BSD License.
        </t>
      </section>
    </boilerplate>
    <toc>
      <section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" pn="section-toc.1">
        <name slugifiedName="name-table-of-contents">Table of Contents</name>
        <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1">
          <li pn="section-toc.1-1.1">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref derivedContent="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-introduction">Introduction</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.1.2">
              <li pn="section-toc.1-1.1.2.1">
                <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.2.1.1"><xref derivedContent="1.1" format="counter" sectionFormat="of" target="section-1.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-terminology">Terminology</xref></t>
              </li>
              <li pn="section-toc.1-1.1.2.2">
                <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.2.2.1"><xref derivedContent="1.2" format="counter" sectionFormat="of" target="section-1.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-requirements-for-a-magic-nu">Requirements for a Magic Number</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.2">
            <t indent="0" pn="section-toc.1-1.2.1"><xref derivedContent="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-protocol">Protocol</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.2.2">
              <li pn="section-toc.1-1.2.2.1">
                <t indent="0" pn="section-toc.1-1.2.2.1.1"><xref derivedContent="2.1" format="counter" sectionFormat="of" target="section-2.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-the-cbor-protocol-specific-">The CBOR-Protocol-Specific Tag</xref></t>
              </li>
              <li pn="section-toc.1-1.2.2.2">
                <t indent="0" pn="section-toc.1-1.2.2.2.1"><xref derivedContent="2.2" format="counter" sectionFormat="of" target="section-2.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-enveloping-method-cbor-tag-">Enveloping Method: CBOR Tag Wrapped</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.2.2.2.2">
                  <li pn="section-toc.1-1.2.2.2.2.1">
                    <t indent="0" pn="section-toc.1-1.2.2.2.2.1.1"><xref derivedContent="2.2.1" format="counter" sectionFormat="of" target="section-2.2.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-example">Example</xref></t>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.2.2.3">
                <t indent="0" pn="section-toc.1-1.2.2.3.1"><xref derivedContent="2.3" format="counter" sectionFormat="of" target="section-2.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-enveloping-method-labeled-c">Enveloping Method: Labeled CBOR Sequence</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.2.2.3.2">
                  <li pn="section-toc.1-1.2.2.3.2.1">
                    <t indent="0" pn="section-toc.1-1.2.2.3.2.1.1"><xref derivedContent="2.3.1" format="counter" sectionFormat="of" target="section-2.3.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-example-2">Example</xref></t>
                  </li>
                </ul>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.3">
            <t indent="0" pn="section-toc.1-1.3.1"><xref derivedContent="3" format="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-security-considerations">Security Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.4">
            <t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" format="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA Considerations</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2">
              <li pn="section-toc.1-1.4.2.1">
                <t indent="0" pn="section-toc.1-1.4.2.1.1"><xref derivedContent="4.1" format="counter" sectionFormat="of" target="section-4.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-labeled-cbor-sequence-tag">Labeled CBOR Sequence Tag</xref></t>
              </li>
              <li pn="section-toc.1-1.4.2.2">
                <t indent="0" pn="section-toc.1-1.4.2.2.1"><xref derivedContent="4.2" format="counter" sectionFormat="of" target="section-4.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-cbor-labeled-non-cbor-data-">CBOR-Labeled Non-CBOR Data Tag</xref></t>
              </li>
              <li pn="section-toc.1-1.4.2.3">
                <t indent="0" pn="section-toc.1-1.4.2.3.1"><xref derivedContent="4.3" format="counter" sectionFormat="of" target="section-4.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-cbor-tags-for-coap-content-">CBOR Tags for CoAP Content-Format Numbers</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.5">
            <t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" format="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-references">References</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.5.2">
              <li pn="section-toc.1-1.5.2.1">
                <t indent="0" pn="section-toc.1-1.5.2.1.1"><xref derivedContent="5.1" format="counter" sectionFormat="of" target="section-5.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-normative-references">Normative References</xref></t>
              </li>
              <li pn="section-toc.1-1.5.2.2">
                <t indent="0" pn="section-toc.1-1.5.2.2.1"><xref derivedContent="5.2" format="counter" sectionFormat="of" target="section-5.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">Informative References</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.6">
            <t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="Appendix A" format="default" sectionFormat="of" target="section-appendix.a"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-advice-to-protocol-designer">Advice to Protocol Designer</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.6.2">
              <li pn="section-toc.1-1.6.2.1">
                <t indent="0" pn="section-toc.1-1.6.2.1.1"><xref derivedContent="A.1" format="counter" sectionFormat="of" target="section-appendix.a.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-is-the-on-wire-format-new">Is the on-wire format new?</xref></t>
              </li>
              <li pn="section-toc.1-1.6.2.2">
                <t indent="0" pn="section-toc.1-1.6.2.2.1"><xref derivedContent="A.2" format="counter" sectionFormat="of" target="section-appendix.a.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-can-many-items-be-trivially">Can many items be trivially concatenated?</xref></t>
              </li>
              <li pn="section-toc.1-1.6.2.3">
                <t indent="0" pn="section-toc.1-1.6.2.3.1"><xref derivedContent="A.3" format="counter" sectionFormat="of" target="section-appendix.a.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-are-there-tags-at-the-start">Are there tags at the start?</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.7">
            <t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="Appendix B" format="default" sectionFormat="of" target="section-appendix.b"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-cbor-tags-for-coap-content-f">CBOR Tags for CoAP Content Formats</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.7.2">
              <li pn="section-toc.1-1.7.2.1">
                <t indent="0" pn="section-toc.1-1.7.2.1.1"><xref derivedContent="B.1" format="counter" sectionFormat="of" target="section-appendix.b.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-content-format-tag-examples">Content-Format Tag Examples</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.8">
            <t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="Appendix C" format="default" sectionFormat="of" target="section-appendix.c"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-example-from-openswan">Example from Openswan</xref></t>
          </li>
          <li pn="section-toc.1-1.9">
            <t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="Appendix D" format="default" sectionFormat="of" target="section-appendix.d"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-using-cbor-labels-for-non-c">Using CBOR Labels for Non-CBOR Data</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.9.2">
              <li pn="section-toc.1-1.9.2.1">
                <t indent="0" pn="section-toc.1-1.9.2.1.1"><xref derivedContent="D.1" format="counter" sectionFormat="of" target="section-appendix.d.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-content-format-tag-examples-2">Content-Format Tag Examples</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.10">
            <t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.e"/><xref derivedContent="" format="title" sectionFormat="of" target="name-acknowledgements">Acknowledgements</xref></t>
          </li>
          <li pn="section-toc.1-1.11">
            <t indent="0" pn="section-toc.1-1.11.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.f"/><xref derivedContent="" format="title" sectionFormat="of" target="name-contributors">Contributors</xref></t>
          </li>
          <li pn="section-toc.1-1.12">
            <t indent="0" pn="section-toc.1-1.12.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.g"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Addresses</xref></t>
          </li>
        </ul>
      </section>
    </toc>
  </front>
  <middle>
    <section anchor="introduction" numbered="true" removeInRFC="false" toc="include" pn="section-1">
      <name slugifiedName="name-introduction">Introduction</name>
      <t indent="0" pn="section-1-1">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; identifying the contents of a stream of bytes became a heuristic activity.</t>
      <t indent="0" pn="section-1-2">For instance, the Unix file(1) command, which has existed since 1973 <xref target="FILE" format="default" sectionFormat="of" derivedContent="FILE"/>, has been able to identify many file formats based upon the contents of the file for decades.</t>
      <t indent="0" pn="section-1-3">Many systems (Linux, macOS, Windows) will select the correct application based upon the file contents if the system cannot determine it by other means.
For instance, in classical Mac OS, 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.</t>
      <t indent="0" pn="section-1-4">Many other systems do this by using file extensions.
Many common Web servers derive the media-type information from file extensions.</t>
      <t indent="0" pn="section-1-5">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, being able to identify the type of information stored in a file can become very important.</t>
      <t indent="0" pn="section-1-6">  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 <xref target="MAGIC" format="default" sectionFormat="of" derivedContent="MAGIC"/>.  In
  the media type registration template <xref target="RFC6838" format="default" sectionFormat="of" derivedContent="RFC6838"/>, a
  magic number is asked for, if available, as is a file extension.
</t>
      <t indent="0" pn="section-1-7">A challenge for the file(1) command is often that it can be confused
by recognizing the overall encoding but not the content being encoded.  For instance, an Android Package Kit 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; the identification may stop at identifying them as ZIP files.
</t>
      <t indent="0" pn="section-1-8">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 <xref target="RFC8742" format="default" sectionFormat="of" derivedContent="RFC8742"/>,
two possible methods of enveloping data are presented; a CBOR Protocol designer will specify one.
(A CBOR Protocol is a specification that uses CBOR as its encoding.)</t>
      <t indent="0" pn="section-1-9">This document also gives advice to designers of CBOR Protocols on
choosing one of these mechanisms for identifying their contents.
This advice is informative.</t>
      <t indent="0" pn="section-1-10">A third method is also proposed by which a CBOR format tag is prepended to identify non-CBOR files.
Further information on this method appears in <xref target="headers" format="default" sectionFormat="of" derivedContent="Appendix D"/> because it is not
about identifying media types containing CBOR-encoded data items.
This includes a simple way to derive a magic number for 
content-formats as defined in <xref target="RFC7252" format="default" sectionFormat="of" derivedContent="RFC7252"/>, even if the file is
not in CBOR form.
</t>
      <t indent="0" pn="section-1-11">Examples of CBOR Protocols currently under development include Concise
Software Identification Tags <xref target="I-D.ietf-sacm-coswid" format="default" sectionFormat="of" derivedContent="CoSWID"/> and
Entity Attestation Tokens <xref target="I-D.ietf-rats-eat" format="default" sectionFormat="of" derivedContent="EAT"/>.
CBOR Object Signing and Encryption (COSE) itself <xref target="RFC8152" format="default" sectionFormat="of" derivedContent="RFC8152"/> is considered infrastructure.
The encoding of public keys in CBOR as <em>C509</em> as described in <xref target="I-D.ietf-cose-cbor-encoded-cert" format="default" sectionFormat="of" derivedContent="C509-CERT"/> would benefit from being an identified CBOR Protocol.</t>
      <t indent="0" pn="section-1-12">A major inspiration for this document is observing the disarray in
certain ASN.1-based systems where most files are Privacy-Enhanced Mail (PEM) encoded; 
these files are all identified by the 
extension "pem", which confounds public keys, private keys, 
certificate requests, and S/MIME content.</t>
      <t indent="0" pn="section-1-13">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.
However, there are some protocols that 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.</t>
      <section anchor="terminology" numbered="true" removeInRFC="false" toc="include" pn="section-1.1">
        <name slugifiedName="name-terminology">Terminology</name>
        <t indent="0" pn="section-1.1-1">Byte is a synonym for octet.
The term "byte string" refers to the data item defined in <xref target="RFC8949" format="default" sectionFormat="of" derivedContent="STD94"/>.</t>
        <t indent="0" pn="section-1.1-2">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.</t>
        <t indent="0" pn="section-1.1-3">The term "diagnostic notation" refers to the human-readable notation
for CBOR data items defined in <xref target="RFC8949" section="8" sectionFormat="of" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8949#section-8" derivedContent="STD94"/> and <xref section="G" sectionFormat="of" target="RFC8610" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8610#appendix-G" derivedContent="RFC8610"/>.</t>
        <t indent="0" pn="section-1.1-4">The term "CDDL" (Concise Data Definition Language) refers to the
language defined in <xref target="RFC8610" format="default" sectionFormat="of" derivedContent="RFC8610"/>.</t>
        <t indent="0" pn="section-1.1-5">The function TN(ct) is defined in <xref target="ct-tags" format="default" sectionFormat="of" derivedContent="Appendix B"/>.</t>
      </section>
      <section anchor="requirements-for-a-magic-number" numbered="true" removeInRFC="false" toc="include" pn="section-1.2">
        <name slugifiedName="name-requirements-for-a-magic-nu">Requirements for a Magic Number</name>
        <t indent="0" pn="section-1.2-1">Ideally, a magic number is a fingerprint that is unique to a specific CBOR Protocol, is present in the first few (small multiple of 4) bytes of the file and does not change when the contents change, and does not depend upon the length of the file.</t>
        <t indent="0" pn="section-1.2-2">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.</t>
      </section>
    </section>
    <section anchor="protocol" numbered="true" removeInRFC="false" toc="include" pn="section-2">
      <name slugifiedName="name-protocol">Protocol</name>
      <t indent="0" pn="section-2-1">This section presents two enveloping methods.
Both use CBOR tags in a way that results in a deterministic first 8 to 12 bytes.
The Protocol designer determines which one to use; see <xref target="advice" format="default" sectionFormat="of" derivedContent="Appendix A"/> for
some guidance.</t>
      <section anchor="spectag" numbered="true" removeInRFC="false" toc="include" pn="section-2.1">
        <name slugifiedName="name-the-cbor-protocol-specific-">The CBOR-Protocol-Specific Tag</name>
        <t indent="0" pn="section-2.1-1">In both enveloping methods,
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.</t>
        <t indent="0" pn="section-2.1-2">The IANA policy for 4-byte CBOR tags is First Come First Served <xref target="RFC8126" format="default" sectionFormat="of" derivedContent="RFC8126"/> so only a simple interaction (e.g., via Web or email) with IANA is required.  The interaction includes filling in the small template provided in <xref target="RFC8949" section="9.2" sectionFormat="of" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8949#section-9.2" derivedContent="STD94"/>.
In the template, a reference to this
specification (RFC 9277) alongside the Description of
semantics is suggested.</t>
        <t indent="0" pn="section-2.1-3">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 4-byte range, and so that there are no
leading zero bytes in the 4-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 4 bytes of their binary representation (such as 0x12003456), as
these may confuse implementations that treat the magic number as a C string.</t>
        <t indent="0" pn="section-2.1-4">The use of a sequence of four ASCII <xref target="RFC0020" format="default" sectionFormat="of" derivedContent="RFC20"/> codes which are mnemonic to the
protocol is encouraged, but not required (there may be reasons to
encode other information into the tag; see <xref target="ct-tags" format="default" sectionFormat="of" derivedContent="Appendix B"/> for an example).
For instance, <xref target="openswan" format="default" sectionFormat="of" derivedContent="Appendix C"/> uses "OPSN", which translates to the tag
number 1330664270 registered for it.</t>
        <t indent="0" pn="section-2.1-5">In <xref target="IANA.CORE-PARAMETERS" format="default" sectionFormat="of" derivedContent="IANA.CORE-PARAMETERS"/>, the Constrained Application Protocol (CoAP) defines the "CoAP Content-Formats" registry to assign Content-Format Numbers (<xref section="12.3" sectionFormat="of" target="RFC7252" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7252#section-12.3" derivedContent="RFC7252"/>) to Content Types in a specific Content Coding.
For CBOR data items that form a representation that is already described by such a Content-Format 
Number, a tag number has proactively been allocated
in <xref target="iana-ct-tags" format="default" sectionFormat="of" derivedContent="Section 4.3"/> (see <xref target="ct-tags" format="default" sectionFormat="of" derivedContent="Appendix B"/> for details and examples).
</t>
      </section>
      <section anchor="wrapped" numbered="true" removeInRFC="false" toc="include" pn="section-2.2">
        <name slugifiedName="name-enveloping-method-cbor-tag-">Enveloping Method: CBOR Tag Wrapped</name>
        <t indent="0" pn="section-2.2-1">The CBOR Tag Wrapped method is appropriate for use with CBOR Protocols that encode a single CBOR data item.
This data item is enveloped into two nested tags:</t>
        <t indent="0" pn="section-2.2-2">The outer tag is a self-described CBOR tag, 55799, as
described in <xref target="RFC8949" sectionFormat="of" section="3.4.6" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8949#section-3.4.6" derivedContent="STD94"/>.</t>
        <t indent="0" pn="section-2.2-3">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 <xref target="spectag" format="default" sectionFormat="of" derivedContent="Section 2.1"/>.
The tag content of this inner tag is the single CBOR data item.</t>
        <t indent="0" pn="section-2.2-4">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 (<xref section="5.10.3" sectionFormat="of" target="RFC7252" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7252#section-5.10.3" derivedContent="RFC7252"/>).
Therefore, a CBOR Protocol specification may 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.</t>
        <section anchor="tag-wrap-example" numbered="true" removeInRFC="false" toc="include" pn="section-2.2.1">
          <name slugifiedName="name-example">Example</name>
          <t indent="0" pn="section-2.2.1-1">To construct an example without registering a new tag, we use 
the Content-Format ID assigned for <tt>application/senml+cbor</tt> (112) <xref target="RFC8428" format="default" sectionFormat="of" derivedContent="RFC8428"/>
of the "CoAP Content-Formats" registry <xref target="IANA.CORE-PARAMETERS" format="default" sectionFormat="of" derivedContent="IANA.CORE-PARAMETERS"/>).</t>
          <t indent="0" pn="section-2.2.1-2">Using the technique described in <xref target="ct-tags" format="default" sectionFormat="of" derivedContent="Appendix B"/>, this translates into the
tag TN(112) = 1668546929.</t>
          <t indent="0" pn="section-2.2.1-3">With this tag, the SenML-CBOR pack <tt>[{0: "current", 6: 3, 2: 1.5}]</tt> would be enveloped as follows (in diagnostic notation):</t>
          <sourcecode type="cbor-diag" markers="false" pn="section-2.2.1-4">
55799(1668546929([{0: "current", 6: 3, 2: 1.5}]))
</sourcecode>
          <t indent="0" pn="section-2.2.1-5">Or in hex:</t>
          <sourcecode type="cbor-pretty" markers="false" pn="section-2.2.1-6">
d9 d9f7                       # tag(55799)
   da 63740171                # tag(1668546929)
      81                      # array(1)
         a3                   # map(3)
            00                # unsigned(0)
            67                # text(7)
               63757272656e74 # "current"
            06                # unsigned(6)
            03                # unsigned(3)
            02                # unsigned(2)
            f9 3e00           # primitive(15872)
</sourcecode>
          <t indent="0" pn="section-2.2.1-7">At the representation level, the unique fingerprint for <tt>application/senml+cbor</tt> is composed of the 8 bytes d9d9f7da63740171 hex, after which the unadorned CBOR data (81... for the SenML data) is appended.</t>
        </section>
      </section>
      <section anchor="sequences" numbered="true" removeInRFC="false" toc="include" pn="section-2.3">
        <name slugifiedName="name-enveloping-method-labeled-c">Enveloping Method: Labeled CBOR Sequence</name>
        <t indent="0" pn="section-2.3-1">The Labeled CBOR Sequence method is appropriate for use with CBOR Sequences as described in <xref target="RFC8742" format="default" sectionFormat="of" derivedContent="RFC8742"/>.</t>
        <t indent="0" pn="section-2.3-2">This method prepends a newly constructed, separate data item to the
CBOR Sequence, the <em>label</em>.</t>
        <t indent="0" pn="section-2.3-3">The label is a nesting of two tags, similar to but distinct from the
CBOR Tag Wrapped methods, with an inner tag content of a constant byte
string.
The total length of the label is 12 bytes.</t>
        <ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-2.3-4"><li pn="section-2.3-4.1" derivedCounter="1.">The outer tag is the self-described CBOR Sequence tag, 55800.</li>
          <li pn="section-2.3-4.2" derivedCounter="2.">The inner tag is a CBOR tag from the First Come First Served space that uniquely identifies the CBOR Protocol.
As with the CBOR Tag Wrapped method, the use of a 4-byte tag that encodes without zero bytes is encouraged.</li>
          <li pn="section-2.3-4.3" derivedCounter="3.">The tag content is a 3-byte CBOR byte string containing
0x42_4f_52 ('BOR' in diagnostic notation).</li>
        </ol>
        <t indent="0" pn="section-2.3-5">The outer tag in the label identifies the file as being a CBOR Sequence and does so with all
the desirable properties explained in <xref target="RFC8949" section="3.4.6" sectionFormat="of" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8949#section-3.4.6" derivedContent="STD94"/>.
Specifically, it does not appear to conflict with any known file types, and it is not valid Unicode in any Unicode encoding.</t>
        <t indent="0" pn="section-2.3-6">The inner tag in the label identifies which CBOR Protocol is used, as described above.</t>
        <t indent="0" pn="section-2.3-7">The inner tag content is a constant byte string that is represented as
0x43_42_4f_52, the ASCII characters "CBOR",
which is the CBOR-encoded data item for the 3-byte string
0x42_4f_52 ('BOR' in diagnostic notation).</t>
        <t indent="0" pn="section-2.3-8">The actual CBOR Protocol data then follows as the next data item(s) in the CBOR Sequence, without a need for any further specific tag.
The use of a CBOR Sequence allows the application to trivially remove the first item with the two tags.</t>
        <t indent="0" pn="section-2.3-9">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.</t>
        <section anchor="tag-seq-example" numbered="true" removeInRFC="false" toc="include" pn="section-2.3.1">
          <name slugifiedName="name-example-2">Example</name>
          <t indent="0" pn="section-2.3.1-1">To construct an example without registering a new tag, we use 
ID 272 as assigned for <tt>application/missing-blocks+cbor-seq</tt> of the "CoAP Content-Formats" registry <xref target="RFC9177" format="default" sectionFormat="of" derivedContent="RFC9177"/>.</t>
          <t indent="0" pn="section-2.3.1-2">Using the technique described in <xref target="ct-tags" format="default" sectionFormat="of" derivedContent="Appendix B"/>, this translates into the
tag TN(272) = 1668547090.</t>
          <t indent="0" pn="section-2.3.1-3">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 <tt>0, 8, 15</tt> would be
enveloped as (in diagnostic notation):</t>
          <sourcecode type="cbor-diag" markers="false" pn="section-2.3.1-4">
55800(1668547090('BOR')),
0,
8,
15
</sourcecode>
          <t indent="0" pn="section-2.3.1-5">Or in hex:</t>
          <sourcecode type="cbor-pretty" markers="false" pn="section-2.3.1-6">
# 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)
</sourcecode>
          <t indent="0" pn="section-2.3.1-7">At the representation level, the unique fingerprint for
<tt>application/missing-blocks+cbor-seq</tt> is composed of the 8 bytes
d9d9f8da63740212 hex, after which the unadorned CBOR sequence
(00... for the missing block list given) is appended.</t>
        </section>
      </section>
    </section>
    <section anchor="security-considerations" numbered="true" removeInRFC="false" toc="include" pn="section-3">
      <name slugifiedName="name-security-considerations">Security Considerations</name>
      <t indent="0" pn="section-3-1">This document provides a way to identify CBOR Protocol objects.
Clearly identifying CBOR contents in files may have a variety of impacts.</t>
      <t indent="0" pn="section-3-2">The most obvious is that it may allow malware to identify interesting
stored objects, and then exfiltrate or corrupt them.</t>
      <t indent="0" pn="section-3-3">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 versus 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 system 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.
</t>
    </section>
    <section anchor="iana-considerations" numbered="true" removeInRFC="false" toc="include" pn="section-4">
      <name slugifiedName="name-iana-considerations">IANA Considerations</name>
      <t indent="0" pn="section-4-1">These IANA considerations are entirely about CBOR tags in the
"Concise Binary Object Representation (CBOR) Tags" registry <xref target="IANA.CBOR-TAGS" format="default" sectionFormat="of" derivedContent="IANA.CBOR-TAGS"/>.</t>
      <t indent="0" pn="section-4-2"><xref target="cbor-sequence-tag" format="default" sectionFormat="of" derivedContent="Section 4.1"/> documents the allocation for a
CBOR tag to be used in a CBOR sequence to identify the sequence (an
example for using this tag is found in <xref target="openswan" format="default" sectionFormat="of" derivedContent="Appendix C"/>).  <xref target="cbor-labeled-non-cbor-data-tag" format="default" sectionFormat="of" derivedContent="Section 4.2"/> documents the allocation for a CBOR tag to be used in the CBOR-Labeled Non-CBOR Data Enveloping Method (<xref target="headers" format="default" sectionFormat="of" derivedContent="Appendix D"/>, which also shows examples).  
<xref target="iana-ct-tags" format="default" sectionFormat="of" derivedContent="Section 4.3"/> allocates a CBOR tag for each actual or
potential CoAP Content-Format number (examples are in <xref target="ct-tags" format="default" sectionFormat="of" derivedContent="Appendix B"/>).</t>
      <section anchor="cbor-sequence-tag" numbered="true" removeInRFC="false" toc="include" pn="section-4.1">
        <name slugifiedName="name-labeled-cbor-sequence-tag">Labeled CBOR Sequence Tag</name>
        <t indent="0" pn="section-4.1-1">IANA has allocated tag 55800 for the Labeled CBOR Sequence
Enveloping Method from the "CBOR Tags" registry.
IANA has updated this tag registration to point to this document.</t>
        <t indent="0" pn="section-4.1-2">This tag is from the First Come First Served area.</t>
        <t indent="0" pn="section-4.1-3">The value has been picked to have properties similar to the 55799 tag (<xref target="RFC8949" sectionFormat="of" section="3.4.6" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8949#section-3.4.6" derivedContent="STD94"/>).</t>
        <t indent="0" pn="section-4.1-4">The hexadecimal representation of the encoded tag head is 0xd9_d9_f8.</t>
        <t indent="0" pn="section-4.1-5">This is not valid UTF-8: the first 0xd9 introduces a 3-byte sequence in UTF-8, but the 0xd9 as the second value is not a valid second byte for UTF-8.</t>
        <t indent="0" pn="section-4.1-6">This is not valid UTF-16: the byte sequence 0xd9d9 (in either endian order) puts this value into the UTF-16 high-half zone, which would signal that this is a 32-bit Unicode value.  However, the following 16-bit big-endian value 0xf8_xx is not a valid second sequence according to <xref target="RFC2781" format="default" sectionFormat="of" derivedContent="RFC2781"/>.
On a little-endian system, it would be necessary to examine the fourth byte to determine if it is valid.  That next byte is determined by the subsequent encoding, and <xref target="RFC8949" section="3.4.6" sectionFormat="of" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8949#section-3.4.6" derivedContent="STD94"/> has already determined that no valid CBOR encodings result in valid UTF-16.</t>
        <dl newline="true" indent="3" spacing="normal" pn="section-4.1-7">
          <dt pn="section-4.1-7.1">Data Item:</dt>
          <dd pn="section-4.1-7.2">
            <t indent="0" pn="section-4.1-7.2.1">tagged byte string
            </t>
          </dd>
          <dt pn="section-4.1-7.3">Semantics:</dt>
          <dd pn="section-4.1-7.4">
            <t indent="0" pn="section-4.1-7.4.1">indicates that the file contains CBOR Sequences</t>
          </dd>
        </dl>
      </section>
      <section anchor="cbor-labeled-non-cbor-data-tag" numbered="true" removeInRFC="false" toc="include" pn="section-4.2">
        <name slugifiedName="name-cbor-labeled-non-cbor-data-">CBOR-Labeled Non-CBOR Data Tag</name>
        <t indent="0" pn="section-4.2-1">IANA has allocated tag 55801 for the CBOR-Labeled Non-CBOR Data
Enveloping Method (<xref target="headers" format="default" sectionFormat="of" derivedContent="Appendix D"/>) from the "CBOR Tags" registry.
IANA updated this tag registration to point to this document.</t>
        <t indent="0" pn="section-4.2-2">This tag is from the First Come First Served area.</t>
        <t indent="0" pn="section-4.2-3">The value has been picked to have properties similar to the 55799 tag (<xref target="RFC8949" section="3.4.6" sectionFormat="of" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8949#section-3.4.6" derivedContent="STD94"/>).</t>
        <t indent="0" pn="section-4.2-4">The hexadecimal representation of the encoded tag head is 0xd9_d9_f9.</t>
        <t indent="0" pn="section-4.2-5">This is not valid UTF-8: the first 0xd9 introduces a 3-byte sequence in UTF-8, but the 0xd9 as the second value is not a valid second byte for UTF-8.</t>
        <t indent="0" pn="section-4.2-6">This is not valid UTF-16: the byte sequence 0xd9d9 (in either endian order) puts this value into the UTF-16 high-half zone, which would signal that this is a 32-bit Unicode value.  However, the following 16-bit big-endian value 0xf9_xx is not a valid second sequence according to <xref target="RFC2781" format="default" sectionFormat="of" derivedContent="RFC2781"/>.
On a little-endian system, it would be necessary to examine the fourth byte to determine if it is valid.  That next byte is determined by the subsequent encoding, and <xref target="RFC8949" sectionFormat="of" section="3.4.6" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8949#section-3.4.6" derivedContent="STD94"/> has already determined that no valid CBOR encodings result in valid UTF-16.</t>
        <dl newline="true" indent="3" spacing="normal" pn="section-4.2-7">
          <dt pn="section-4.2-7.1">Data Item:</dt>
          <dd pn="section-4.2-7.2">
            <t indent="0" pn="section-4.2-7.2.1">tagged byte string
            </t>
          </dd>
          <dt pn="section-4.2-7.3">Semantics:</dt>
          <dd pn="section-4.2-7.4">
            <t indent="0" pn="section-4.2-7.4.1">indicates that the file starts with a CBOR-Labeled Non-CBOR Data label.</t>
          </dd>
        </dl>
      </section>
      <section anchor="iana-ct-tags" numbered="true" removeInRFC="false" toc="include" pn="section-4.3">
        <name slugifiedName="name-cbor-tags-for-coap-content-">CBOR Tags for CoAP Content-Format Numbers</name>
        <t indent="0" pn="section-4.3-1">IANA allocated the tag numbers 1668546817 (0x63740101) to
1668612095 (0x6374ffff) as follows:</t>
        <dl newline="true" indent="3" spacing="normal" pn="section-4.3-2">
          <dt pn="section-4.3-2.1">Data Item:</dt>
          <dd pn="section-4.3-2.2">
            <t indent="0" pn="section-4.3-2.2.1">byte string or any CBOR data item (see <xref target="ct-tags" format="default" sectionFormat="of" derivedContent="Appendix B"/>)</t>
          </dd>
          <dt pn="section-4.3-2.3">Semantics:</dt>
          <dd pn="section-4.3-2.4">
            <t indent="0" pn="section-4.3-2.4.1">the representation of content-format ct &lt; 65025 is indicated by
tag number <br/>
TN(ct) = 0x63740101 + (ct / 255) * 256 + ct % 255</t>
          </dd>
          <dt pn="section-4.3-2.5">Reference:</dt>
          <dd pn="section-4.3-2.6">
            <t indent="0" pn="section-4.3-2.6.1">RFC 9277</t>
          </dd>
        </dl>
        <t indent="0" pn="section-4.3-3">The "CoAP Content-Formats" registry <xref target="IANA.CORE-PARAMETERS" format="default" sectionFormat="of" derivedContent="IANA.CORE-PARAMETERS"/> is defined in <xref section="12.3" sectionFormat="of" target="RFC7252" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7252#section-12.3" derivedContent="RFC7252"/>.</t>
      </section>
    </section>
  </middle>
  <back>
    <displayreference target="I-D.ietf-cose-cbor-encoded-cert" to="C509-CERT"/>
    <displayreference target="I-D.ietf-rats-eat" to="EAT"/>
    <displayreference target="I-D.ietf-sacm-coswid" to="CoSWID"/>
    <displayreference target="RFC0020" to="RFC20"/>
    <displayreference target="RFC8949" to="STD94"/>
    <references pn="section-5">
      <name slugifiedName="name-references">References</name>
      <references pn="section-5.1">
        <name slugifiedName="name-normative-references">Normative References</name>
        <reference anchor="C" target="https://www.iso.org/standard/74528.html" quoteTitle="true" derivedAnchor="C">
          <front>
            <title>Information technology -- Programming languages -- C</title>
            <author>
              <organization showOnFrontPage="true">International Organization for Standardization</organization>
            </author>
            <date year="2018" month="June"/>
          </front>
          <seriesInfo name="ISO/IEC" value="9899:2018, Fourth Edition"/>
        </reference>
        <reference anchor="RFC8742" target="https://www.rfc-editor.org/info/rfc8742" quoteTitle="true" derivedAnchor="RFC8742">
          <front>
            <title>Concise Binary Object Representation (CBOR) Sequences</title>
            <author fullname="C. Bormann" initials="C." surname="Bormann"/>
            <date month="February" year="2020"/>
            <abstract>
              <t indent="0">This document describes the Concise Binary Object Representation (CBOR) Sequence format and associated media type "application/cbor-seq". A CBOR Sequence consists of any number of encoded CBOR data items, simply concatenated in sequence.</t>
              <t indent="0">Structured syntax suffixes for media types allow other media types to build on them and make it explicit that they are built on an existing media type as their foundation. This specification defines and registers "+cbor-seq" as a structured syntax suffix for CBOR Sequences.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8742"/>
          <seriesInfo name="DOI" value="10.17487/RFC8742"/>
        </reference>
        <reference anchor="RFC8949" target="https://www.rfc-editor.org/info/std94" quoteTitle="true" derivedAnchor="STD94">
          <front>
            <title>Concise Binary Object Representation (CBOR)</title>
            <author initials="C." surname="Bormann" fullname="C. Bormann">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="P." surname="Hoffman" fullname="P. Hoffman">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2020" month="December"/>
          </front>
          <seriesInfo name="STD" value="94"/>
          <seriesInfo name="RFC" value="8949"/>
          <seriesInfo name="DOI" value="10.17487/RFC8949"/>
        </reference>
      </references>
      <references pn="section-5.2">
        <name slugifiedName="name-informative-references">Informative References</name>
        <reference anchor="I-D.ietf-cose-cbor-encoded-cert" quoteTitle="true" target="https://datatracker.ietf.org/doc/html/draft-ietf-cose-cbor-encoded-cert-04" derivedAnchor="C509-CERT">
          <front>
            <title>CBOR Encoded X.509 Certificates (C509 Certificates)</title>
            <author fullname="John Preuß Mattsson">
              <organization showOnFrontPage="true">Ericsson AB</organization>
            </author>
            <author fullname="Göran Selander">
              <organization showOnFrontPage="true">Ericsson AB</organization>
            </author>
            <author fullname="Shahid Raza">
              <organization showOnFrontPage="true">RISE AB</organization>
            </author>
            <author fullname="Joel Höglund">
              <organization showOnFrontPage="true">RISE AB</organization>
            </author>
            <author fullname="Martin Furuhed">
              <organization showOnFrontPage="true">Nexus Group</organization>
            </author>
            <date month="July" day="10" year="2022"/>
            <abstract>
              <t indent="0">   This document specifies a CBOR encoding of X.509 certificates.  The
   resulting certificates are called C509 Certificates.  The CBOR
   encoding supports a large subset of RFC 5280 and all certificates
   compatible with the RFC 7925, IEEE 802.1AR (DevID), CNSA, RPKI, GSMA
   eUICC, and CA/Browser Forum Baseline Requirements profiles.  When
   used to re-encode DER encoded X.509 certificates, the CBOR encoding
   can in many cases reduce the size of RFC 7925 profiled certificates
   with over 50%.  The CBOR encoded structure can alternatively be
   signed directly ("natively signed"), which does not require re-
   encoding for the signature to be verified.  The document also
   specifies C509 COSE headers, a C509 TLS certificate type, and a C509
   file format.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-cose-cbor-encoded-cert-04"/>
          <format type="TXT" target="https://www.ietf.org/archive/id/draft-ietf-cose-cbor-encoded-cert-04.txt"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="I-D.ietf-sacm-coswid" quoteTitle="true" target="https://datatracker.ietf.org/doc/html/draft-ietf-sacm-coswid-22" derivedAnchor="CoSWID">
          <front>
            <title>Concise Software Identification Tags</title>
            <author fullname="Henk Birkholz">
              <organization showOnFrontPage="true">Fraunhofer SIT</organization>
            </author>
            <author fullname="Jessica Fitzgerald-McKay">
              <organization showOnFrontPage="true">National Security Agency</organization>
            </author>
            <author fullname="Charles Schmidt">
              <organization showOnFrontPage="true">The MITRE Corporation</organization>
            </author>
            <author fullname="David Waltermire">
              <organization showOnFrontPage="true">National Institute of Standards and Technology</organization>
            </author>
            <date month="July" day="20" year="2022"/>
            <abstract>
              <t indent="0">   ISO/IEC 19770-2:2015 Software Identification (SWID) tags provide an
   extensible XML-based structure to identify and describe individual
   software components, patches, and installation bundles.  SWID tag
   representations can be too large for devices with network and storage
   constraints.  This document defines a concise representation of SWID
   tags: Concise SWID (CoSWID) tags.  CoSWID supports a similar set of
   semantics and features as SWID tags, as well as new semantics that
   allow CoSWIDs to describe additional types of information, all in a
   more memory efficient format.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-sacm-coswid-22"/>
          <format type="TXT" target="https://www.ietf.org/archive/id/draft-ietf-sacm-coswid-22.txt"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="I-D.ietf-rats-eat" quoteTitle="true" target="https://datatracker.ietf.org/doc/html/draft-ietf-rats-eat-14" derivedAnchor="EAT">
          <front>
            <title>The Entity Attestation Token (EAT)</title>
            <author fullname="Laurence Lundblade">
              <organization showOnFrontPage="true">Security Theory LLC</organization>
            </author>
            <author fullname="Giridhar Mandyam">
              <organization showOnFrontPage="true">Qualcomm Technologies Inc.</organization>
            </author>
            <author fullname="Jeremy O'Donoghue">
              <organization showOnFrontPage="true">Qualcomm Technologies Inc.</organization>
            </author>
            <date month="July" day="10" year="2022"/>
            <abstract>
              <t indent="0">   An Entity Attestation Token (EAT) provides an attested claims set
   that describes state and characteristics of an entity, a device like
   a phone, IoT device, network equipment or such.  This claims set is
   used by a relying party, server or service to determine how much it
   wishes to trust the entity.

   An EAT is either a CBOR Web Token (CWT) or JSON Web Token (JWT) with
   attestation-oriented claims.  To a large degree, all this document
   does is extend CWT and JWT.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-rats-eat-14"/>
          <format type="TXT" target="https://www.ietf.org/archive/id/draft-ietf-rats-eat-14.txt"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="FILE" target="https://en.wikipedia.org/w/index.php?title=File_(command)&amp;oldid=1096086462" quoteTitle="true" derivedAnchor="FILE">
          <front>
            <title>file (command)</title>
            <author>
              <organization showOnFrontPage="true">Wikipedia</organization>
            </author>
            <date year="2022" month="July" day="2"/>
          </front>
        </reference>
        <reference anchor="IANA.CBOR-TAGS" target="https://www.iana.org/assignments/cbor-tags" quoteTitle="true" derivedAnchor="IANA.CBOR-TAGS">
          <front>
            <title>Concise Binary Object Representation (CBOR) Tags</title>
            <author>
              <organization showOnFrontPage="true">IANA</organization>
            </author>
          </front>
        </reference>
        <reference anchor="IANA.CORE-PARAMETERS" target="https://www.iana.org/assignments/core-parameters" quoteTitle="true" derivedAnchor="IANA.CORE-PARAMETERS">
          <front>
            <title>Constrained RESTful Environments (CoRE) Parameters</title>
            <author>
              <organization showOnFrontPage="true">IANA</organization>
            </author>
          </front>
        </reference>
        <reference anchor="MAGIC" target="https://www.bell-labs.com/usr/dmr/www/man51.pdf#page=4" quoteTitle="true" derivedAnchor="MAGIC">
          <front>
            <title>archive (library) file format</title>
            <author>
              <organization showOnFrontPage="true">Bell Labs</organization>
            </author>
            <date year="1971" month="November" day="3"/>
          </front>
          <refcontent>Unix Programmer's Manual, First Edition: File Formats</refcontent>
        </reference>
        <reference anchor="RFC0020" target="https://www.rfc-editor.org/info/rfc20" quoteTitle="true" derivedAnchor="RFC20">
          <front>
            <title>ASCII format for network interchange</title>
            <author fullname="V.G. Cerf" initials="V.G." surname="Cerf"/>
            <date month="October" year="1969"/>
          </front>
          <seriesInfo name="STD" value="80"/>
          <seriesInfo name="RFC" value="20"/>
          <seriesInfo name="DOI" value="10.17487/RFC0020"/>
        </reference>
        <reference anchor="RFC2781" target="https://www.rfc-editor.org/info/rfc2781" quoteTitle="true" derivedAnchor="RFC2781">
          <front>
            <title>UTF-16, an encoding of ISO 10646</title>
            <author fullname="P. Hoffman" initials="P." surname="Hoffman"/>
            <author fullname="F. Yergeau" initials="F." surname="Yergeau"/>
            <date month="February" year="2000"/>
            <abstract>
              <t indent="0">This document describes the UTF-16 encoding of Unicode/ISO-10646, addresses the issues of serializing UTF-16 as an octet stream for transmission over the Internet, discusses MIME charset naming as described in [CHARSET-REG], and contains the registration for three MIME charset parameter values: UTF-16BE (big-endian), UTF-16LE (little- endian), and UTF-16.  This memo provides information for the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="2781"/>
          <seriesInfo name="DOI" value="10.17487/RFC2781"/>
        </reference>
        <reference anchor="RFC6838" target="https://www.rfc-editor.org/info/rfc6838" quoteTitle="true" derivedAnchor="RFC6838">
          <front>
            <title>Media Type Specifications and Registration Procedures</title>
            <author fullname="N. Freed" initials="N." surname="Freed"/>
            <author fullname="J. Klensin" initials="J." surname="Klensin"/>
            <author fullname="T. Hansen" initials="T." surname="Hansen"/>
            <date month="January" year="2013"/>
            <abstract>
              <t indent="0">This document defines procedures for the specification and registration of media types for use in HTTP, MIME, and other Internet protocols.  This memo documents an Internet Best Current Practice.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="13"/>
          <seriesInfo name="RFC" value="6838"/>
          <seriesInfo name="DOI" value="10.17487/RFC6838"/>
        </reference>
        <reference anchor="RFC7252" target="https://www.rfc-editor.org/info/rfc7252" quoteTitle="true" derivedAnchor="RFC7252">
          <front>
            <title>The Constrained Application Protocol (CoAP)</title>
            <author fullname="Z. Shelby" initials="Z." surname="Shelby"/>
            <author fullname="K. Hartke" initials="K." surname="Hartke"/>
            <author fullname="C. Bormann" initials="C." surname="Bormann"/>
            <date month="June" year="2014"/>
            <abstract>
              <t indent="0">The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for use with constrained nodes and constrained (e.g., low-power, lossy) networks. The nodes often have 8-bit microcontrollers with small amounts of ROM and RAM, while constrained networks such as IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) often have high packet error rates and a typical throughput of 10s of kbit/s. The protocol is designed for machine- to-machine (M2M) applications such as smart energy and building automation.</t>
              <t indent="0">CoAP provides a request/response interaction model between application endpoints, supports built-in discovery of services and resources, and includes key concepts of the Web such as URIs and Internet media types. CoAP is designed to easily interface with HTTP for integration with the Web while meeting specialized requirements such as multicast support, very low overhead, and simplicity for constrained environments.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7252"/>
          <seriesInfo name="DOI" value="10.17487/RFC7252"/>
        </reference>
        <reference anchor="RFC8017" target="https://www.rfc-editor.org/info/rfc8017" quoteTitle="true" derivedAnchor="RFC8017">
          <front>
            <title>PKCS #1: RSA Cryptography Specifications Version 2.2</title>
            <author fullname="K. Moriarty" initials="K." role="editor" surname="Moriarty"/>
            <author fullname="B. Kaliski" initials="B." surname="Kaliski"/>
            <author fullname="J. Jonsson" initials="J." surname="Jonsson"/>
            <author fullname="A. Rusch" initials="A." surname="Rusch"/>
            <date month="November" year="2016"/>
            <abstract>
              <t indent="0">This document provides recommendations for the implementation of public-key cryptography based on the RSA algorithm, covering cryptographic primitives, encryption schemes, signature schemes with appendix, and ASN.1 syntax for representing keys and for identifying the schemes.</t>
              <t indent="0">This document represents a republication of PKCS #1 v2.2 from RSA Laboratories' Public-Key Cryptography Standards (PKCS) series. By publishing this RFC, change control is transferred to the IETF.</t>
              <t indent="0">This document also obsoletes RFC 3447.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8017"/>
          <seriesInfo name="DOI" value="10.17487/RFC8017"/>
        </reference>
        <reference anchor="RFC8126" target="https://www.rfc-editor.org/info/rfc8126" quoteTitle="true" derivedAnchor="RFC8126">
          <front>
            <title>Guidelines for Writing an IANA Considerations Section in RFCs</title>
            <author fullname="M. Cotton" initials="M." surname="Cotton"/>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <author fullname="T. Narten" initials="T." surname="Narten"/>
            <date month="June" year="2017"/>
            <abstract>
              <t indent="0">Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA).</t>
              <t indent="0">To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry.</t>
              <t indent="0">This is the third edition of this document; it obsoletes RFC 5226.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="26"/>
          <seriesInfo name="RFC" value="8126"/>
          <seriesInfo name="DOI" value="10.17487/RFC8126"/>
        </reference>
        <reference anchor="RFC8152" target="https://www.rfc-editor.org/info/rfc8152" quoteTitle="true" derivedAnchor="RFC8152">
          <front>
            <title>CBOR Object Signing and Encryption (COSE)</title>
            <author fullname="J. Schaad" initials="J." surname="Schaad"/>
            <date month="July" year="2017"/>
            <abstract>
              <t indent="0">Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size.  There is a need for the ability to have basic security services defined for this data format.  This document defines the CBOR Object Signing and Encryption (COSE) protocol.  This specification describes how to create and process signatures, message authentication codes, and encryption using CBOR for serialization.  This specification additionally describes how to represent cryptographic keys using CBOR.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8152"/>
          <seriesInfo name="DOI" value="10.17487/RFC8152"/>
        </reference>
        <reference anchor="RFC8428" target="https://www.rfc-editor.org/info/rfc8428" quoteTitle="true" derivedAnchor="RFC8428">
          <front>
            <title>Sensor Measurement Lists (SenML)</title>
            <author fullname="C. Jennings" initials="C." surname="Jennings"/>
            <author fullname="Z. Shelby" initials="Z." surname="Shelby"/>
            <author fullname="J. Arkko" initials="J." surname="Arkko"/>
            <author fullname="A. Keranen" initials="A." surname="Keranen"/>
            <author fullname="C. Bormann" initials="C." surname="Bormann"/>
            <date month="August" year="2018"/>
            <abstract>
              <t indent="0">This specification defines a format for representing simple sensor measurements and device parameters in Sensor Measurement Lists (SenML).  Representations are defined in JavaScript Object Notation (JSON), Concise Binary Object Representation (CBOR), Extensible Markup Language (XML), and Efficient XML Interchange (EXI), which share the common SenML data model.  A simple sensor, such as a temperature sensor, could use one of these media types in protocols such as HTTP or the Constrained Application Protocol (CoAP) to transport the measurements of the sensor or to be configured.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8428"/>
          <seriesInfo name="DOI" value="10.17487/RFC8428"/>
        </reference>
        <reference anchor="RFC8610" target="https://www.rfc-editor.org/info/rfc8610" quoteTitle="true" derivedAnchor="RFC8610">
          <front>
            <title>Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures</title>
            <author fullname="H. Birkholz" initials="H." surname="Birkholz"/>
            <author fullname="C. Vigano" initials="C." surname="Vigano"/>
            <author fullname="C. Bormann" initials="C." surname="Bormann"/>
            <date month="June" year="2019"/>
            <abstract>
              <t indent="0">This document proposes a notational convention to express Concise Binary Object Representation (CBOR) data structures (RFC 7049).  Its main goal is to provide an easy and unambiguous way to express structures for protocol messages and data formats that use CBOR or JSON.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8610"/>
          <seriesInfo name="DOI" value="10.17487/RFC8610"/>
        </reference>
        <reference anchor="RFC9110" target="https://www.rfc-editor.org/info/rfc9110" quoteTitle="true" derivedAnchor="RFC9110">
          <front>
            <title>HTTP Semantics</title>
            <author fullname="R. Fielding" initials="R." role="editor" surname="Fielding"/>
            <author fullname="M. Nottingham" initials="M." role="editor" surname="Nottingham"/>
            <author fullname="J. Reschke" initials="J." role="editor" surname="Reschke"/>
            <date month="June" year="2022"/>
            <abstract>
              <t indent="0">The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes.</t>
              <t indent="0">This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230.</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="97"/>
          <seriesInfo name="RFC" value="9110"/>
          <seriesInfo name="DOI" value="10.17487/RFC9110"/>
        </reference>
        <reference anchor="RFC9177" target="https://www.rfc-editor.org/info/rfc9177" quoteTitle="true" derivedAnchor="RFC9177">
          <front>
            <title>Constrained Application Protocol (CoAP) Block-Wise Transfer Options Supporting Robust Transmission</title>
            <author fullname="M. Boucadair" initials="M." surname="Boucadair"/>
            <author fullname="J. Shallow" initials="J." surname="Shallow"/>
            <date month="March" year="2022"/>
            <abstract>
              <t indent="0">This document specifies alternative Constrained Application Protocol (CoAP) block-wise transfer options: Q-Block1 and Q-Block2.</t>
              <t indent="0">These options are similar to, but distinct from, the CoAP Block1 and Block2 options defined in RFC 7959. The Q-Block1 and Q-Block2 options are not intended to replace the Block1 and Block2 options but rather have the goal of supporting Non-confirmable (NON) messages for large amounts of data with fewer packet interchanges. Also, the Q-Block1 and Q-Block2 options support faster recovery should any of the blocks get lost in transmission.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9177"/>
          <seriesInfo name="DOI" value="10.17487/RFC9177"/>
        </reference>
        <reference anchor="X.690" target="https://www.itu.int/rec/T-REC-X.690" quoteTitle="true" derivedAnchor="X.690">
          <front>
            <title>Information technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)</title>
            <author>
              <organization showOnFrontPage="true">ITU-T</organization>
            </author>
            <date year="2021" month="February"/>
          </front>
          <seriesInfo name="ITU-T Recommendation" value="X.690"/>
          <seriesInfo name="ISO/IEC" value="8825-1"/>
        </reference>
      </references>
    </references>
    <section anchor="advice" numbered="true" removeInRFC="false" toc="include" pn="section-appendix.a">
      <name slugifiedName="name-advice-to-protocol-designer">Advice to Protocol Designer</name>
      <t indent="0" pn="section-appendix.a-1">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 a single data item).</t>
      <t indent="0" pn="section-appendix.a-2">Which should a protocol designer use?</t>
      <t indent="0" pn="section-appendix.a-3">In this discussion, one assumes that there is an object stored in a file, perhaps specified by a system operator in a configuration file.</t>
      <t indent="0" pn="section-appendix.a-4">For example: a private key used in COSE operations, a public key/certificate in C509 <xref target="I-D.ietf-cose-cbor-encoded-cert" format="default" sectionFormat="of" derivedContent="C509-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.</t>
      <t indent="0" pn="section-appendix.a-5">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.</t>
      <t indent="0" pn="section-appendix.a-6">The Labeled CBOR Sequence can be slightly easier to remove as, in most cases, CBOR parsers will return it as a unit and then return the actual CBOR item, which could be anything at all and could include CBOR tags that <em>do</em> need to be sent on the wire.</t>
      <t indent="0" pn="section-appendix.a-7">On the other hand, having the Labeled CBOR Sequence in the file requires that all programs that expect to examine that file be able to skip what appears to be a CBOR item with two tags nested around a 3-byte byte string.
The 3-byte entry is not of the format the program would normally have processed, so it may be a surprise.
On the other hand, CBOR parsers are generally tolerant of tags that appear: many of them will process extra tags, making unknown tags available as meta information.
A program that is not expecting those tags may just ignore them.</t>
      <t indent="0" pn="section-appendix.a-8">As an example of where there was a problem with previous security systems, "PEM" format certificate files grew to be able to contain multiple certificates by simple concatenation.

The PKCS1 format <xref target="RFC8017" format="default" sectionFormat="of" derivedContent="RFC8017"/> could also contain a private key object followed by one or more certificate objects, but only when in PEM format.
Annoyingly, when in binary DER format (<xref target="X.690" format="default" sectionFormat="of" derivedContent="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.</t>
      <t indent="0" pn="section-appendix.a-9">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 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.
Other tags present might be needed.</t>
      <t indent="0" pn="section-appendix.a-10">For a representation matching a specific media-type that is carried in
a CBOR byte string, the byte string head will already have to be
removed for use as such a representation, so it should be easy to
remove the enclosing tag heads as well.
This is of particular interest with the predefined tags provided in
<xref target="ct-tags" format="default" sectionFormat="of" derivedContent="Appendix B"/> for media types with CoAP Content-Format numbers.</t>
      <t indent="0" pn="section-appendix.a-11">Some considerations in the form of survey questions follow.</t>
      <section anchor="is-the-on-wire-format-new" numbered="true" removeInRFC="false" toc="include" pn="section-appendix.a.1">
        <name slugifiedName="name-is-the-on-wire-format-new">Is the on-wire format new?</name>
        <t indent="0" pn="section-appendix.a.1-1">If the on-wire format is new, then it could be specified with the CBOR Tag Wrapped format if the extra 8 bytes are not a problem.
The stored format is then identical to the on-wire format.</t>
        <t indent="0" pn="section-appendix.a.1-2">If the 8 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.</t>
      </section>
      <section anchor="can-many-items-be-trivially-concatenated" numbered="true" removeInRFC="false" toc="include" pn="section-appendix.a.2">
        <name slugifiedName="name-can-many-items-be-trivially">Can many items be trivially concatenated?</name>
        <t indent="0" pn="section-appendix.a.2-1">If the programs that read the contents of the file already expect to process all of the CBOR data items in the file (not just the first), then the Labeled CBOR Sequence format may be easily retrofitted.</t>
        <t indent="0" pn="section-appendix.a.2-2">The programs 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.</t>
        <t indent="0" pn="section-appendix.a.2-3">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
multiple such labels in the file.</t>
        <t indent="0" pn="section-appendix.a.2-4">A protocol based on CBOR Sequences may specify that Labeled CBOR
Sequence labels can occur within a CBOR Sequence, possibly even to
switch to data items following in the sequence that are of a different type.</t>
        <t indent="0" pn="section-appendix.a.2-5">If the CBOR-Sequence-based protocol does not define the semantics for
or at least tolerate embedded labels, care must be taken when
concatenating Labeled CBOR Sequences to remove the label from all but
the first part.</t>
        <aside pn="section-appendix.a.2-6">
          <t indent="0" pn="section-appendix.a.2-6.1">As an example from legacy PEM-encoded PKIX certificates, many programs accept a series of PKIX certificates in a single file in order to set up a certificate chain.
The file would contain not just the End-Entity (EE) certificate, but also any subordinate certification authorities (CAs) needed to validate the EE.
This mechanism actually only works for PEM-encoded certificates, and not DER-encoded certificates.
One of the reasons for this specification is to make sure that CBOR-encoded certificates do not suffer from this problem.</t>
          <t indent="0" pn="section-appendix.a.2-6.2">As an example of mixing of types, some TLS server programs also can accept both their PEM-encoded private key and their PEM-encoded certificate in the same file.</t>
        </aside>
        <t indent="0" pn="section-appendix.a.2-7">If only one item is ever expected in the file, the use of the Labeled CBOR Sequence may present an implementation hurdle to programs that previously just read a single data item and used it.</t>
      </section>
      <section anchor="are-there-tags-at-the-start" numbered="true" removeInRFC="false" toc="include" pn="section-appendix.a.3">
        <name slugifiedName="name-are-there-tags-at-the-start">Are there tags at the start?</name>
        <t indent="0" pn="section-appendix.a.3-1">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.</t>
      </section>
    </section>
    <section anchor="ct-tags" numbered="true" removeInRFC="false" toc="include" pn="section-appendix.b">
      <name slugifiedName="name-cbor-tags-for-coap-content-f">CBOR Tags for CoAP Content Formats</name>
      <t indent="0" pn="section-appendix.b-1"><xref section="5.10.3" sectionFormat="of" target="RFC7252" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7252#section-5.10.3" derivedContent="RFC7252"/> defines the concept of a Content-Format,
which is a short, 16-bit unsigned integer that identifies a specific
content type (media type plus (optionally) parameters), optionally
together with a content coding (see <xref target="RFC9110" section="8.4.1" sectionFormat="of" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9110#section-8.4.1" derivedContent="RFC9110"/>).
</t>
      <t indent="0" pn="section-appendix.b-2">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.</t>
      <t indent="0" pn="section-appendix.b-3">This specification allocates CBOR tag numbers 1668546817 (0x63740101) to
1668612095 (0x6374FFFF) for the tagging of representations of specific
content formats.</t>
      <t indent="0" pn="section-appendix.b-4">Using tags from this range, a byte string that is to be interpreted as
a representation of Content-Format number <tt>ct</tt>, with ct &lt; 65025
(255*255), can be identified by enclosing it in a tag with tag number
<tt>TN(ct)</tt> where:</t>
      <ul empty="true" bare="false" indent="3" spacing="normal" pn="section-appendix.b-5">
        <li pn="section-appendix.b-5.1">
          <t indent="0" pn="section-appendix.b-5.1.1">TN(ct) = 0x63740101 + (ct / 255) * 256 + ct % 255.</t>
        </li>
      </ul>
      <t indent="0" pn="section-appendix.b-6">(where <tt>+</tt>, <tt>*</tt>, <tt>/</tt> and <tt>%</tt> stand for integer addition,
multiplication, division, and remainder as in the programming language C <xref target="C" format="default" sectionFormat="of" derivedContent="C"/>.)</t>
      <aside pn="section-appendix.b-7">
        <t indent="0" pn="section-appendix.b-7.1">This formula avoids the use of zero bytes in the representation of
the tag number.</t>
        <t indent="0" pn="section-appendix.b-7.2">Note that no tag numbers are assigned for Content-Format numbers in
the following range:</t>
        <artwork align="left" pn="section-appendix.b-7.3">65025 ≤ ct ≤ 65535</artwork>
        <t indent="0" pn="section-appendix.b-7.4">(This range is in the range reserved for Experimental Use <xref target="RFC8126" format="default" sectionFormat="of" derivedContent="RFC8126"/> by <xref section="12.3" sectionFormat="of" target="RFC7252" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7252#section-12.3" derivedContent="RFC7252"/>.
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.)</t>
      </aside>
      <t indent="0" pn="section-appendix.b-8">Exceptionally, when used immediately as tag content of one of the tags
55799, 55800, or 55801, the tag content is as follows:</t>
      <dl indent="3" newline="false" spacing="normal" pn="section-appendix.b-9">
        <dt pn="section-appendix.b-9.1">Tag 55799 (<xref target="wrapped" format="default" sectionFormat="of" derivedContent="Section 2.2"/>):</dt>
        <dd pn="section-appendix.b-9.2">
          <t indent="0" pn="section-appendix.b-9.2.1">One of:
</t>
          <ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-appendix.b-9.2.2"><li pn="section-appendix.b-9.2.2.1" derivedCounter="1.">The CBOR data item within the representation (without byte-string
wrapping).  This only works for Content-Formats that are represented
by a single CBOR data item in identity content-coding.</li>
            <li pn="section-appendix.b-9.2.2.2" derivedCounter="2.">The data items in the CBOR sequence within the representation, without byte string
wrapping, but wrapped in a CBOR array.
This works for Content-Formats that are represented
by a CBOR sequence in identity content-coding.</li>
          </ol>
        </dd>
        <dt pn="section-appendix.b-9.3">Tags 55800 (<xref target="sequences" format="default" sectionFormat="of" derivedContent="Section 2.3"/>) or 55801 (<xref target="headers" format="default" sectionFormat="of" derivedContent="Appendix D"/>):</dt>
        <dd pn="section-appendix.b-9.4">
          <t indent="0" pn="section-appendix.b-9.4.1">the byte string 'BOR', signifying that the representation of the
given content-format follows in the file, in the way defined for these tags.</t>
        </dd>
      </dl>
      <section anchor="ct-examples" numbered="true" removeInRFC="false" toc="include" pn="section-appendix.b.1">
        <name slugifiedName="name-content-format-tag-examples">Content-Format Tag Examples</name>
        <t indent="0" pn="section-appendix.b.1-1">The "CoAP Content-Formats" registry <xref target="IANA.CORE-PARAMETERS" format="default" sectionFormat="of" derivedContent="IANA.CORE-PARAMETERS"/> defines content formats that can be used as examples:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-appendix.b.1-2">
          <li pn="section-appendix.b.1-2.1">
            <t indent="0" pn="section-appendix.b.1-2.1.1">As discussed in <xref target="tag-wrap-example" format="default" sectionFormat="of" derivedContent="Section 2.2.1"/>, Content-Format ID 112 represents the application/senml+cbor media type (no parameters).
The corresponding tag number is TN(112) = 1668546929.  </t>
            <t indent="0" pn="section-appendix.b.1-2.1.2">
The following CDDL snippet can be used to identify
application/senml+cbor representations:  </t>
            <sourcecode type="cddl" markers="false" pn="section-appendix.b.1-2.1.3">
senml-cbor = #6.1668546929(bstr)
</sourcecode>
            <t indent="0" pn="section-appendix.b.1-2.1.4">
Note that a byte string is used as the type of the tag content because a
media type representation in general can be any byte string.</t>
          </li>
          <li pn="section-appendix.b.1-2.2">
            <t indent="0" pn="section-appendix.b.1-2.2.1">Content-Format ID 272 represents the 
application/missing-blocks+cbor-seq media type, which is a CBOR sequence
<xref target="RFC9177" format="default" sectionFormat="of" derivedContent="RFC9177"/>.  </t>
            <t indent="0" pn="section-appendix.b.1-2.2.2">
The corresponding tag number is TN(272) = 1668547090.  </t>
            <t indent="0" pn="section-appendix.b.1-2.2.3">
The following CDDL snippet can be used to identify
application/missing-blocks+cbor-seq representations as embedded in a
CBOR byte string:  </t>
            <sourcecode type="cddl" markers="false" pn="section-appendix.b.1-2.2.4">
missing-blocks = #6.1668547090(bstr)
</sourcecode>
          </li>
        </ul>
      </section>
    </section>
    <section anchor="openswan" numbered="true" removeInRFC="false" toc="include" pn="section-appendix.c">
      <name slugifiedName="name-example-from-openswan">Example from Openswan</name>
      <t indent="0" pn="section-appendix.c-1">The Openswan IPsec project has a daemon ("pluto") and two control programs ("addconn" and "whack"). 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.</t>
      <t indent="0" pn="section-appendix.c-2">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.
The above magic number is included in the file and on the IPC in order to distinguish the "shutdown" command CBOR operation.</t>
      <t indent="0" pn="section-appendix.c-3">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 any implementation language to be used that can encode CBOR.
</t>
      <t indent="0" pn="section-appendix.c-4">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 Sequence tag.</t>
      <t indent="0" pn="section-appendix.c-5">In diagnostic notation:</t>
      <sourcecode type="cbor-diag" markers="false" pn="section-appendix.c-6">
55800(1330664270(h'424F52'))
</sourcecode>
      <t indent="0" pn="section-appendix.c-7">Or in hex:</t>
      <sourcecode type="cbor-pretty" markers="false" pn="section-appendix.c-8">
d9 d9f8         # tag(55800)
   da 4f50534e  # tag(1330664270)
      43        # bytes(3)
         424f52 # "BOR"
</sourcecode>
    </section>
    <section anchor="headers" numbered="true" removeInRFC="false" toc="include" pn="section-appendix.d">
      <name slugifiedName="name-using-cbor-labels-for-non-c">Using CBOR Labels for Non-CBOR Data</name>
      <t indent="0" pn="section-appendix.d-1">The CBOR-Labeled Non-CBOR data method is appropriate for adding a magic number to a
Non-CBOR data format, particularly one that can be described by a
Content-Format tag (<xref target="ct-tags" format="default" sectionFormat="of" derivedContent="Appendix B"/>).</t>
      <t indent="0" pn="section-appendix.d-2">This method prepends a CBOR data item to the Non-CBOR data; this data
item is called the "header" and, similar to the Labeled
CBOR-Sequence label, consists of two nested tags around a constant
byte string for a total of 12 bytes.</t>
      <ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-appendix.d-3"><li pn="section-appendix.d-3.1" derivedCounter="1.">The outer tag is the CBOR-Labeled Non-CBOR Data tag, 55801.</li>
        <li pn="section-appendix.d-3.2" derivedCounter="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 4-byte tag is encouraged that encodes without zero bytes.</li>
        <li pn="section-appendix.d-3.3" derivedCounter="3.">The tag content is a 3-byte CBOR byte string containing
0x42_4F_52 ('BOR' in diagnostic notation).</li>
      </ol>
      <t indent="0" pn="section-appendix.d-4">The outer tag in the label identifies the file as being prefixed by a Non-CBOR
data label and does so with all
the desirable properties explained in <xref target="RFC8949" section="3.4.6" sectionFormat="of" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8949#section-3.4.6" derivedContent="STD94"/>.
Specifically, it does not appear to conflict with any known file types, and it is not valid Unicode in any Unicode encoding.</t>
      <t indent="0" pn="section-appendix.d-5">The inner tag in the label identifies which Non-CBOR Protocol is used.</t>
      <t indent="0" pn="section-appendix.d-6">The inner tag content is a constant byte string that is represented as
0x43_42_4f_52, the ASCII characters "CBOR",
which is the CBOR-encoded data item for the 3-byte string
0x42_4f_52 ('BOR' in diagnostic notation).</t>
      <t indent="0" pn="section-appendix.d-7">The actual Non-CBOR Protocol data then follow directly appended to the
CBOR representation of the header.
This allows the application to trivially remove the header item with
the two nested tags and the byte string.</t>
      <t indent="0" pn="section-appendix.d-8">As with the Labeled CBOR Sequence {#sequences}, this choice of the tag
content places the ASCII characters "CBOR" prominently into the
header.</t>
      <section anchor="header-ct-examples" numbered="true" removeInRFC="false" toc="include" pn="section-appendix.d.1">
        <name slugifiedName="name-content-format-tag-examples-2">Content-Format Tag Examples</name>
        <t indent="0" pn="section-appendix.d.1-1">The "CoAP Content-Formats" registry <xref target="IANA.CORE-PARAMETERS" format="default" sectionFormat="of" derivedContent="IANA.CORE-PARAMETERS"/> defines content formats that can be used as examples:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-appendix.d.1-2">
          <li pn="section-appendix.d.1-2.1">
            <t indent="0" pn="section-appendix.d.1-2.1.1">Content-Format ID 432 represents the application/td+json media type (no
parameters).</t>
            <t indent="0" pn="section-appendix.d.1-2.1.2">The corresponding tag number is TN(432) = 1668547250.  </t>
            <t indent="0" pn="section-appendix.d.1-2.1.3">
The following CDDL snippet can be used to identify a CBOR-Labeled Non-CBOR data for application/td+json representations:  </t>
            <sourcecode type="cddl" markers="false" pn="section-appendix.d.1-2.1.4">
td-json-header = #6.55801(#6.1668547250('BOR'))
</sourcecode>
          </li>
          <li pn="section-appendix.d.1-2.2">
            <t indent="0" pn="section-appendix.d.1-2.2.1">Content-Format 11050 represents the application/json media type in
deflate content-coding.  </t>
            <t indent="0" pn="section-appendix.d.1-2.2.2">
The corresponding tag number is TN(11050) = 1668557910.  </t>
            <t indent="0" pn="section-appendix.d.1-2.2.3">
The following CDDL snippet can be used to identify a CBOR-Labeled Non-CBOR data for application/json representations compressed in deflate content-coding:  </t>
            <sourcecode type="cddl" markers="false" pn="section-appendix.d.1-2.2.4">
json-deflate-header = #6.55801(#6.1668557910('BOR'))
</sourcecode>
          </li>
        </ul>
      </section>
    </section>
    <section numbered="false" anchor="acknowledgements" removeInRFC="false" toc="include" pn="section-appendix.e">
      <name slugifiedName="name-acknowledgements">Acknowledgements</name>
      <t indent="0" pn="section-appendix.e-1">The CBOR WG brainstormed this protocol on January 20, 2021 via a number of productive email exchanges on the mailing list.</t>
    </section>
    <section anchor="contributors" numbered="false" toc="include" removeInRFC="false" pn="section-appendix.f">
      <name slugifiedName="name-contributors">Contributors</name>
      <contact initials="J. 'Jeff'" surname="Sipek" fullname="Josef 'Jeff' Sipek">
        <organization showOnFrontPage="true"/>
        <address>
          <email>jeffpc@josefsipek.net</email>
        </address>
      </contact>
    </section>
    <section anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.g">
      <name slugifiedName="name-authors-addresses">Authors' Addresses</name>
      <author initials="M." surname="Richardson" fullname="Michael Richardson">
        <organization showOnFrontPage="true">Sandelman Software Works</organization>
        <address>
          <email>mcr+ietf@sandelman.ca</email>
        </address>
      </author>
      <author initials="C." surname="Bormann" fullname="Carsten Bormann">
        <organization showOnFrontPage="true">Universität Bremen TZI</organization>
        <address>
          <postal>
            <street>Postfach 330440</street>
            <city>D-28359 Bremen</city>
            <country>Germany</country>
          </postal>
          <phone>+49-421-218-63921</phone>
          <email>cabo@tzi.org</email>
        </address>
      </author>
    </section>
  </back>
</rfc>
