<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902"
     docName="draft-schaad-cbor-content-02" category="info" version="3" submissionType="IETF">
     submissionType="IETF" number="8769" consensus="true" symRefs="true"
     sortRefs="true" tocInclude="true" xml:lang="en">

  <front>
    <title>Cryptographic

    <title abbrev="CMS Content Types for CBOR">Cryptographic Message System Syntax (CMS) Content Types for Concise Binary
    Object Representation (CBOR)</title>
<seriesInfo name="RFC" value="8769" />
    <author initials="J." surname="Schaad" fullname="Jim Schaad">
      <organization>August Cellars</organization>
      <address>
        <email>ietf@augustcellars.com</email>
      </address>
    </author>
    <date/>
    <date month="March" year="2020"/>
    <area>Security</area>

    <abstract>
      <t>
        Concise Binary Object Representation (CBOR) is becoming a widely used method of doing content encoding.
        The Cryptographic Message System Syntax (CMS) is still a widely used method of doing message-based security.
        This document defines a set of content types for CMS that hold CBOR content.
      </t>
    </abstract>
  </front>
  <middle>
    <section>
      <name>Introduction</name>
      <t>
        Concise Binary Object Representation (CBOR) <xref target="RFC7049"/>
	is a compact self-describing binary encoding formation that is
	starting to be used in many different applications.
        One of the primary uses of CBOR is in the Internet of Things where Things, the
	constrained nature of which means that having minimal size of
	encodings becomes very important.
        The use of the Cryptographic Message System Syntax (CMS) <xref
	target="RFC5652"/> is still one of the most common method methods for
	providing message-based security, although in many cases cases, the CBOR
	Object Signing and Encryption (COSE) <xref target="RFC8152"/>
	message-based security system is starting to be used.
        Given that CBOR is going to be transported using CMS, it makes sense
	to define CMS content types for the purpose of denoting that the
	embedded content is CBOR.
        This document defines two new content types: CBOR Content Type content type and
	CBOR Sequence Content Type content type <xref target="I-D.ietf-cbor-sequence"/>. target="RFC8742"/>.
      </t>
    </section>

    <section>
      <name>CBOR Content Type</name>
      <t>
        <xref target="RFC7049"/> defines an encoded CBOR item.
        This section defines a new content type for wrapping an encoded CBOR item in a CMS object.
      </t>

      <t>
        The following object identifier identifies the CBOR content type:
      </t>

      <artwork>
<sourcecode type="asn.1"><![CDATA[
id-ct-cbor OBJECT IDENTIFIER ::= { iso(1) member-body(2) usa(840)
        rsadsi(113549) pkcs(1) pkcs9(9) smime(16) ct(1) TBD1 }
      </artwork> 44 }]]>
</sourcecode>

      <t>
        The CBOR content type is intended to refer to a single object encoded using the CBOR encoding format <xref target="RFC7049"/>.
        Nothing is stated about the specific CBOR object that is included.
        CBOR can always be decoded to a tree tree, as the encoding is self descriptive.
      </t>

      <t>
        The CBOR content type is intended to be encapsulated in the signed
	data and auth-enveloped data, but it can be included in any CMS wrapper.
        It cannot be predicted if whether the compressed CMS encapsulation will
	provide compression as compression, because the content may be binary rather than text.
      </t>

      <t>
        <xref target="RFC7193"/> defined an optional parameter "innerContent" parameter,
	"innerContent", to allow for identification of what the inner content
	is for an application/cms media type.
        This document defines the string "cbor" as a new value that can be
	placed here in this parameter when a CBOR content type is used.
      </t>

    </section>

    <section>
      <name>CBOR Sequence Content Type</name>
      <t>
        <xref target="I-D.ietf-cbor-sequence"/> target="RFC8742"/> defines a CBOR Sequence as a concatenation of zero or more CBOR objects.
        This section defines a new content type for wrapping a CBOR Sequence in a CMS object.
      </t>

      <t>
        The following object identifier identifies the CBOR Sequence content type:
      </t>
      <artwork>

<sourcecode type="asn.1"><![CDATA[
id-ct-cborSequence OBJECT IDENTIFIER ::= { iso(1) member-body(2)
        usa(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) ct(1)
        TBD2 }
      </artwork>
        45 }]]>
</sourcecode>

      <t>
        The CBOR Sequence content type is intended to refer to a sequence of objects encoded using the CBOR encoding format.
        The objects are concatenated without any markers delimiting the individual CBOR objects.
        Nothing is stated about the specific CBOR objects that are included.
        CBOR can always be decoded to a tree as tree, because the encoding is self descriptive.
      </t>

      <t>
        The CBOR Sequence content type is intended to be encapsulated in the
	signed data and auth-enveloped data, but it can be included in any CMS
	wrapper. It cannot be predicted if whether the compressed CMS encapsulation will
	provide compression as compression, because the content may be binary rather than text.
      </t>

      <t>
        <xref target="RFC7193"/> defined an optional parameter "innerContent" parameter, "innerContent", to allow for identification of what the inner content is for an application/cms media type.
        This document defines the string "cborSequence" as a new value that
	can be placed here in this parameter when a CBOR Sequence content type is used.
      </t>
    </section>

    <section>
      <name>ASN.1 Module</name>
      <artwork>

<sourcecode type="asn.1"><![CDATA[
CborContentTypes { iso(1) member-body(2) usa(840)
        rsadsi(113549) pkcs(1) pkcs9(9) smime(16) modules(0)
        id-mod-cbor-2019(TBD3)
        id-mod-cbor-2019(71) }
DEFINITIONS EXPLICIT TAGS ::= BEGIN

IMPORTS
    CONTENT-TYPE
    FROM  CryptographicMessageSyntax-2010
      { iso(1) member-body(2) us(840) rsadsi(113549)
         pkcs(1) pkcs-9(9) smime(16) modules(0) id-mod-cms-2009(58) }
    ;

    id-ct-cbor OBJECT IDENTIFIER ::= { iso(1) member-body(2)
        us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) ct(1)
        TBD1
        44 }

    id-ct-cborSequence OBJECT IDENTIFIER ::= { iso(1) member-body(2)
        us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) ct(1)
        TBD2
        45 }

    -- Content is encoded directly and does not have any ASN.1
    --    structure
    ct-Cbor CONTENT-TYPE ::= { IDENTIFIED BY id-ct-cbor }

    -- Content is encoded directly and does not have any ASN.1
    --    structure
    ct-CborSequence CONTENT-TYPE ::= {
        IDENTIFIED BY id-ct-cborSequence
    }

END
      </artwork>

END]]>
</sourcecode>

    </section>

    <section>
      <name>IANA Considerations</name>
      <t>
        In
        IANA has registered the following in the "SMI Security for S/MIME
	Module Identifier" registry, create a new entry to point to this document. Identifier (1.2.840.113549.1.9.16.0)" subregistry within the
	SMI Numbers registry:
      </t>
      <table>
        <thead>
          <tr>
            <td>Decimal</td><td>Description</td><td>References</td>
            <th>Decimal</th>
	    <th>Description</th>
	    <th>References</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td>TBD3</td><td>id-mod-cbor-2019</td><td>[[This Document]]</td>
            <td>71</td><td>id-mod-cbor-2019</td><td>RFC 8769</td>
          </tr>
        </tbody>
      </table>

      <t>
        In
        IANA has registered the following in the
	"SMI Security for S/MIME CMS Content Types" registry, add two new entries for id-ct-cbor and id-ct-cborSequence that point to this document. Type (1.2.840.113549.1.9.16.1)"
	subregistry within the SMI Numbers registry:
      </t>

      <table>
        <thead>
          <tr>
            <td>Decimal</td><td>Description</td><td>References</td>
            <th>Decimal</th><th>Description</th><th>References</th>
          </tr>
        </thead>
        <tbody>
        <tr>
          <td>TBD1</td><td>id-ct-cbor</td><td>[[This Document]]</td>
          <td>44</td><td>id-ct-cbor</td><td>RFC 8769</td>
        </tr>
        <tr>
          <td>TBD2</td><td>id-ct-cborSequence</td><td>[[This Document]]</td>
          <td>45</td><td>id-ct-cborSequence</td><td>RFC 8769</td>
        </tr>
        </tbody>
      </table>

      <t>
        In
        IANA has registered the following in the table "CMS Inner Content Types" add two new entries:
	subregistry within the "MIME Media Type Sub-Parameter Registries":
      </t>

      <table>
        <thead>
          <tr>
            <td>Name</td><td>Object Identifier</td><td>Reference</td>
            <th>Name</th><th>Object Identifier</th><th>Reference</th>
          </tr>
        </thead>
        <tbody>
        <tr>
          <td>cbor</td><td>1.2.840.113549.1.9.16.1.TBD1</td><td>[[This Document]]</td>
          <td>cbor</td><td>1.2.840.113549.1.9.16.1.44</td><td>RFC 8769</td>
        </tr>
        <tr>
          <td>cborSequence</td><td>1.2.840.113549.1.9.16.1.TBD2</td><td>[[This Document]]</td>
          <td>cborSequence</td><td>1.2.840.113549.1.9.16.1.45</td><td>RFC 8769</td>
        </tr>
        </tbody>
      </table>
    </section>

    <section>
      <name>Security Considerations</name>
      <t>
        This document only provides identification for content types, types; it does
	not introduce any new security issues by itself.
        The new content types mean that id-data does not need to be used to
	identify these content types and thus types; they can therefore reduce confusion.
      </t>
    </section>
  </middle>
  <back>
    <displayreference target="RFC5652" to="CMS"/>
    <displayreference target="RFC7049" to="CBOR"/>
    <displayreference target="RFC8152" to="COSE"/>
    <displayreference target="I-D.ietf-cbor-sequence" target="RFC8742" to="CBOR-SEQ"/>

    <references>
      <name>Normative References</name>

      <?rfc include="reference.RFC.5652.xml" ?>
      <?rfc include="reference.RFC.7049.xml" ?>
      <?rfc include="reference.RFC.8152.xml" ?>
      <?rfc include="reference.RFC.7193.xml" ?>
      <?rfc include="reference.I-D.ietf-cbor-sequence.xml" ?>

      <xi:include
	  href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5652.xml"/>

<xi:include
    href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7049.xml"/>

<xi:include
    href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8152.xml"/>

<xi:include
    href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7193.xml"/>

      <xi:include
	  href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8742.xml"/>

</references>
  </back>
</rfc>