RFC 8769

Cryptographic Message Syntax (CMS) Content Types for Concise Binary Object Representation (CBOR)

📅 published March 2020, from ietf

🎀 RFC 8769: CMS Content Types for CBOR, bestie 🎀

Title block first! This one is an RFC 8769 ✨, titled Cryptographic Message Syntax (CMS) Content Types for Concise Binary Object Representation (CBOR). It's by J. Schaad (that's Jim Schaad) at August Cellars 💜. The category is Informational 📚, it's from the Internet Engineering Task Force (IETF), the ISSN is 2070-1721, and the date is March 2020 🗓️. The header doesn't list anything it obsoletes or updates, so there's no drama there 🙈.

Abstract 🌸

okay so CBOR is getting super popular as a way to do content encoding 🧚. CMS is still one of the most used ways to do message-based security, so this doc sets up a bunch of CMS content types that carry CBOR content. It's giving compatibility, fr 💅.

Status of This Memo 📜

ngl this part is the boring legal bit, but it's important 🫶. This document is not an Internet Standards Track specification. It's published for informational purposes 📚.

It's a product of the IETF, it reflects the consensus of the IETF community 🌈, and it got public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every IESG-approved doc is a candidate for any level of Internet Standard, so check Section 2 of RFC 7841 if you want the details 🔍.

For the current status, any errata, and how to send feedback, go to https://www.rfc-editor.org/info/rfc8769 🔗.

Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved 💖.

This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents, which you can find at https://trustee.ietf.org/license-info, as they were in effect on the publication date. Please actually read those, bestie, because they spell out your rights and restrictions 📖. Code Components pulled out of this doc must include the Simplified BSD License text described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as the Simplified BSD License describes ⚖️.

Table of Contents 🗂️

  • 1. Introduction
  • 2. CBOR Content Type
  • 3. CBOR Sequence Content Type
  • 4. ASN.1 Module
  • 5. IANA Considerations
  • 6. Security Considerations
  • 7. Normative References
  • Author's Address

1. Introduction ✨

okay so CBOR [CBOR] is a compact, self-describing binary encoding formation that's starting to show up in tons of apps 🦋. One of its biggest uses is the Internet of Things, where devices are constrained, so tiny encodings matter a LOT 🥺.

CMS [CMS] is still one of the most common ways to do message-based security. Meanwhile, the CBOR Object Signing and Encryption (COSE) [COSE] message-based security system is starting to get used too 👀. Since CBOR is going to get carried around inside CMS, it makes total sense to define CMS content types that say "hey, this embedded content is CBOR" 🎀.

This doc defines two new content types: the CBOR content type, and the CBOR Sequence content type [CBOR-SEQ] 🌈.

2. CBOR Content Type 💜

[CBOR] defines an encoded CBOR item. This section adds a new content type for wrapping one encoded CBOR item in a CMS object 🎁.

The object identifier for the CBOR content type is:

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

This content type is meant to refer to a single object encoded with the CBOR encoding format [CBOR]. Nothing is said about which specific CBOR object is included 🤷‍♀️. CBOR can always be decoded to a tree, because the encoding is self descriptive 🌳.

The CBOR content type is meant to be encapsulated in signed data and auth-enveloped data, but it can go inside any CMS wrapper 🎀. Whether the compressed CMS encapsulation actually compresses anything can't be predicted, because the content might be binary instead of text 😭.

[RFC7193] defined an optional parameter called "innerContent" that says what the inner content is for an application/cms media type 📦. This doc adds the string cbor as a new value for that parameter, to use when the CBOR content type is in play ✨.

3. CBOR Sequence Content Type 🧚

[CBOR-SEQ] defines a CBOR Sequence as a concatenation of zero or more CBOR objects 🔗. This section adds a new content type for wrapping a CBOR Sequence in a CMS object 💅.

The object identifier for the CBOR Sequence content type is:

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

This content type is meant to refer to a sequence of objects encoded with the CBOR encoding format. The objects are just stuck together back to back, with no markers between them 🧩. Nothing is said about which specific CBOR objects are included 🙈. CBOR can always be decoded to a tree, because the encoding is self descriptive 🌳.

The CBOR Sequence content type is meant to be encapsulated in signed data and auth-enveloped data, but it can go inside any CMS wrapper 🎀. Like before, nobody can predict whether the compressed CMS encapsulation will compress, since the content might be binary rather than text 😭.

[RFC7193] defined an optional parameter called "innerContent" for the application/cms media type 📦. This doc adds the string cborSequence as a new value for that parameter, for when the CBOR Sequence content type is used 🌸.

4. ASN.1 Module 🧾

Here's the ASN.1 module, verbatim, because it's giving precision 🤓:

CborContentTypes { iso(1) member-body(2) usa(840)
        rsadsi(113549) pkcs(1) pkcs9(9) smime(16) modules(0)
        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)
        44 }

    id-ct-cborSequence OBJECT IDENTIFIER ::= { iso(1) member-body(2)
        us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) ct(1)
        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

5. IANA Considerations 🏛️

okay IANA's got a few registrations to note 📋. First up, this goes in the "SMI Security for S/MIME Module Identifier (1.2.840.113549.1.9.16.0)" subregistry, inside the SMI Numbers registry 💜:

+---------+------------------+------------+
| Decimal | Description      | References |
+=========+==================+============+
| 71      | id-mod-cbor-2019 | RFC 8769   |
+---------+------------------+------------+

                  Table 1

Next, this goes in the "SMI Security for S/MIME CMS Content Type (1.2.840.113549.1.9.16.1)" subregistry, also inside the SMI Numbers registry 🎀:

+---------+--------------------+------------+
| Decimal | Description        | References |
+=========+====================+============+
| 44      | id-ct-cbor         | RFC 8769   |
+---------+--------------------+------------+
| 45      | id-ct-cborSequence | RFC 8769   |
+---------+--------------------+------------+

                  Table 2

And finally, IANA adds these to the "CMS Inner Content Types" subregistry, which lives in the "MIME Media Type Sub-Parameter Registries" 🌈:

+--------------+----------------------------+-----------+
| Name         | Object Identifier          | Reference |
+==============+============================+===========+
| cbor         | 1.2.840.113549.1.9.16.1.44 | RFC 8769  |
+--------------+----------------------------+-----------+
| cborSequence | 1.2.840.113549.1.9.16.1.45 | RFC 8769  |
+--------------+----------------------------+-----------+

                  Table 3

6. Security Considerations 🚨

⚠️ Serious security moment, bestie. This document only provides identification for content types. It does not introduce any new security issues by itself 🔒.

The new content types mean that id-data doesn't need to be used to identify these content types, so they can cut down on confusion 🙌.

7. Normative References 📚

Author's Address 💌

Jim Schaad August Cellars

Email: ietf@augustcellars.com

That's the whole RFC, bestie! 🌈💖✨

📦 where this page comes from