RFC 7193

The application/cms Media Type

📅 published April 2014, from ietf

RFC 7193: The application/cms Media Type 🎀

Okay bestie, the title block tea ☕: this is RFC 7193, published in April 2014 as Informational 🌸 That means it's for info only, not a Standards Track thing. It's part of the IETF stream, ISSN 2070-1721, and the authors are:

  • S. Turner from IECA 💖
  • R. Housley from Vigil Security ✨
  • J. Schaad from Soaring Hawk Consulting 🦋

Abstract 🌈

This doc registers the application/cms media type so you can use it with the matching CMS (Cryptographic Message Syntax) content types. It's giving "official paperwork that makes everything line up" 💅

Status of This Memo 📚

Quick check first: this document is not an Internet Standards Track specification. It's published for informational purposes, so no pressure 🫶

It's still a product of the IETF, though, and it represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every IESG-approved doc is up for any level of Internet Standard, though. Check out Section 2 of RFC 5741 if you want the deets 🧐

If you want the current status, any errata, or a way to send feedback, head to http://www.rfc-editor.org/info/rfc7193 🔥

Copyright (c) 2014 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 (http://trustee.ietf.org/license-info), as they were on the date it was published. Please read those carefully, because they spell out your rights and restrictions for this doc 📜 Any Code Components pulled from this doc must include the Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions. They're also provided without warranty, as described in the Simplified BSD License 🫶

1. Introduction ✨

Okay so, [RFC5751] registered the application/pkc7-mime media type. That doc defined five optional smime-type parameters. The smime-type parameter first told you about the security applied to the data content type: whether it was signed or enveloped, plus the name of the data content. It was later expanded to show whether the data content is compressed and whether it contained a certs-only message. This doc doesn't change any of those registrations, since it places no requirements on S/MIME (Secure Multipurpose Internet Mail Extensions) agents 💅

The S/MIME registrations assumed there'd be a MIME (Multipurpose Internet Mail Extensions) wrapping layer around each of the different enveloping contents. So there was no need to include more than one item in each smime-type. That's no longer the case with some of the more advanced enveloping types 👑 Some protocols, like CMC (Certificate Management over Cryptographic Message Syntax) [RFC5273], have defined extra S/MIME types. New protocols that want to wrap MIME content should keep defining a smime-type string. New protocols that want to wrap non-MIME types should use this mechanism instead 🦋

CMS (Cryptographic Message Syntax) [RFC5652] links a content type identifier (OID) to specific content. CMS content types have been used a lot to define contents that can be enveloped using other CMS content types, and to define enveloping content types, some of which provide security services 🔐

The protecting content types are the ones that provide security services. They include Signed-Data [RFC5652], Enveloped-Data [RFC5652], Digested-Data [RFC5652], Encrypted-Data [RFC5652], Authenticated-Data [RFC5652], Authenticated-Enveloped-Data [RFC5083], and Encrypted Key Package [RFC6032] 🛡️

The non-protecting content types provide no security services but encapsulate other CMS content types. They include Content Information [RFC5652], Compressed Data [RFC3274], Content Collection [RFC4073], and Content With Attributes [RFC4073] 🎁

Then there are the innermost content types: Data [RFC5652], Asymmetric Key Package [RFC5958], Symmetric Key Package [RFC6031], Firmware Package [RFC4108], Firmware Package Load Receipt [RFC4108], Firmware Package Load Error [RFC4108], Trust Anchor List [RFC5914], TAMP Status Query, TAMP Status Response, TAMP Update, TAMP Update Confirm, TAMP Apex Update, TAMP Apex Update Confirmation, TAMP Community Update, TAMP Community Update Confirm, TAMP Sequence Adjust, TAMP Sequence Adjust Confirmation, TAMP Error [RFC5934], Key Package Error, and Key Package Receipt [RFC7191] 🧚

To help carry CMS content types, this doc defines a media type and parameters that show the enveloping and embedded CMS content types 🎀

Now, the vibe check for new CMS content types: they should be affirmative about the string that identifies the new content type. They should also say whether that new content type is expected to show up in the encapsulatedContent or innerContent parameter 🫶

1.1. Requirements Terminology 🧠

Here's the important part, so read closely 👀 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Those words are the BCP 14 vibes, so they carry real weight 💖

2. CMS Media Type Registration Applications 📝

This section gives the media type registration application for the application/cms media type. You can find the template in [RFC6838], Section 5.6 💅

  • Type name: application
  • Subtype name: cms
  • Required parameters: None.
  • Optional parameters:

The optional parameters are a whole thing, so here's the first one 💜 encapsulatingContent=y;, where y is one or more CMS ECT (Encapsulating Content Type) identifiers. Multiple values get wrapped in quotes and separated by a folding-whitespace, a comma, and folding-whitespace. The ECT values are based on content types found in [RFC3274], [RFC4073], [RFC5083], [RFC5652], and [RFC6032]. This list can be extended later, see Section 4 🌸

authData
compressedData
contentCollection
contentInfo
contentWithAttrs
authEnvelopedData
encryptedKeyPkg
digestData
encryptedData
envelopedData
signedData

The second optional parameter is innerContent=x;, where x is one or more CMS ICT (Inner Content Type) identifiers. Multiple values are wrapped in quotes and separated by a folding-whitespace, a comma, and folding-whitespace. The ICT values are based on content types found in [RFC4108], [RFC5914], [RFC5934], [RFC5958], [RFC6031], and [RFC7191]. This list can be extended later too, see Section 4 🦋

firmwarePackage
firmwareLoadReceipt
firmwareLoadError
aKeyPackage
sKeyPackage
trustAnchorList
TAMP-statusQuery
TAMP-statusResponse
TAMP-update
TAMP-updateConfirm
TAMP-apexUpdate
TAMP-apexUpdateConfirm
TAMP-communityUpdate
TAMP-communityUpdateConfirm
TAMP-seqNumAdjust
TAMP-seqNumAdjustConfirm
TAMP-error
keyPackageReceipt
keyPackageError

Heads up: the optional parameters are case sensitive 🙈 Capitalization matters, so don't be sloppy with it ✨

  • Encoding considerations: Binary.

[RFC5652] requires that the outermost encapsulation be ContentInfo. That's the rule 💅

  • Security considerations:

The following security considerations apply. Heads up, this part is serious 😭

Here's the table of CMS protecting content types and their algorithms, copied exactly as written:

RFC       | CMS Protecting Content Type and Algorithms
----------+-------------------------------------------
[RFC3370] | signedData, envelopedData,
[RFC5652] | digestedData, encryptedData, and
[RFC5753] | authData
[RFC5754] |
----------+-------------------------------------------
[RFC5958] | aKeyPackage
[RFC5959] |
[RFC6162] |
----------+-------------------------------------------
[RFC6031] | sKeyPackage
[RFC6160] |
----------+-------------------------------------------
[RFC6032] | encryptedKeyPkg
[RFC6033] |
[RFC6161] |
----------+-------------------------------------------
[RFC5914] | trustAnchorList
----------+-------------------------------------------
[RFC3274] | compressedData
----------+-------------------------------------------
[RFC5083] | authEnvelopedData
[RFC5084] |
----------+-------------------------------------------
[RFC4073] | contentCollection and
          | contentWithAttrs
----------+-------------------------------------------
[RFC4108] | firmwarePackage,
          | firmwareLoadReceipt, and
          | firmwareLoadError
----------+-------------------------------------------
[RFC5934] | TAMP-statusQuery, TAMP-statusResponse,
          | TAMP-update, TAMP-updateConfirm,
          | TAMP-apexUpdate,
          | TAMP-apexUpdateConfirm,
          | TAMP-communityUpdate,
          | TAMP-communityUpdateConfirm,
          | TAMP-seqNumAdjust,
          | TAMP-seqNumAdjustConfirm, and
          | TAMP-error
----------+-------------------------------------------
[RFC7191] |keyPackageReceipt and keyPackageError
----------+-------------------------------------------

Now the security drama 🚨 In some circumstances, a ton of information can leak just from disclosing what the innermost ASN.1 structure is. In those cases, it's acceptable to disclose the wrappers without disclosing the inner content type 🙈

ASN.1 encoding rules (like DER and BER) use a type-length-value structure. It's really easy to build malicious content with invalid length fields that can cause buffer overrun conditions 💀 ASN.1 encoding rules allow arbitrary levels of nesting, which may make it possible to build malicious content that causes a stack overflow. Anyone interpreting ASN.1 structures should be aware of these issues and should take appropriate measures to guard against buffer overflows and stack overruns in particular, and malicious content in general. Stay safe out there 🛡️

  • Interoperability considerations:

See [RFC3274], [RFC4073], [RFC4108], [RFC5083], [RFC5652], [RFC5914], [RFC5934], [RFC5958], [RFC6031], [RFC6032], and [RFC7191] 💜

In all cases, CMS content types are encapsulated within ContentInfo structures [RFC5652]. In other words, the outermost enveloping structure is ContentInfo 🎀

[RFC5652] defines slightly different processing rules for SignedData than PKCS #7 [RFC2315] does. This media type uses the CMS processing rules 🧠

The Content-Type header field of all application/cms objects SHOULD include the optional "encapsulatingContent" and "innerContent" parameters. Yes, that's a capital SHOULD, so it's a big deal 🔥

The Content-Disposition header field [RFC4021] can also be included, along with the Content-Type's optional name parameter 🌸

  • Published specification: This specification.
  • Applications that use this media type: Applications that support CMS (Cryptographic Message Syntax) content types.
  • Fragment identifier considerations: N/A
  • Additional information:
    • Magic number(s): None
    • File extension(s): .cmsc
    • Macintosh File Type Code(s):
  • Person & email address to contact for further information: Sean Turner <turners@ieca.com>
  • Intended usage: COMMON
  • Restrictions on usage: none
  • Author: Sean Turner <turners@ieca.com>
  • Change controller: The IESG <iesg@ietf.org> 👑

3. Example 🎀

okay bestie, this is the example encrypted status response message 😭✨ Carl Wallace made it, so it's giving real-world vibes. The headers come first, then the base64 body:

      MIME-Version: 1.0
      Content-Type: application/cms; encapsulatingContent=encryptedData;
                    innerContent=TAMP-statusResponse; name=status.cmsc
      Content-Transfer-Encoding: base64

      MIIFLQYJKoZIhvcNAQcDoIIFHjCCBRoCAQAxggFhMIIBXQIBADBFMEAxC
      zAJBgNVBAYTAlVTMR8wHQYDVQQKExZUZXN0IENlcnRpZmljYXRlcyAyMD
      ExMRAwDgYDVQQDEwdHb29kIENBAgEBMA0GCSqGSIb3DQEBAQUABIIBAEa
      uaXQeVsOyZ7gz0pJikRQ6Jqr64k2dbHBE4SDZL/uErP9FJUIja9LaJrc5
      S83EZ7wf3mODUBaDhGfQVKoPrNTsLmw98fE/O+wcdpI2XKaILOR62xDJR
      emQQST+EPfMwZmCwgsImmY3AxefAgzp8hVgK7SDiXGXfa9ux9PMdCSjHP
      IgcAUFHmTiqxYd72Gl08kLCMIXmn3g5RsYUggxooeFNHiFNR28TV5HctG
      i6Ay5++iKUGrUQyXD+GlwakFToGFmFj3FMyZi7+kYV/X00BiBP3kpIgVJ
      4jCj+nYtKWh6JXPoEqEsa39GmDEFGq4/58GEu70amWvW1DA++7kDP4gwg
      gOuBgkqhkiG9w0BBwEwHQYJYIZIAWUDBAECBBCH5yTQqZ4KYiTTeYdjoY
      4sgIIDgArSpOcengKnZS4SCjfuQkMxB5wfSaud1thlZ+gUFCgzbFtkfYM
      Qx/T7gnkneniyj2rwOmZxCQXpPlCDXH6mS83ngfrNN8ay3HrMPpVkEOmW
      UMc5jI6oNObwqi8a3ezzhYRxF06jzdD2R/6SAPALz3Q4NU8eX+PnuekgR
      oxo/INzhT4iGvokn9xVah6piSbjhPA+QZp1HgQrlWyyM3lG9jn4thchKl
      FQqZEy/EBaCWq+sJG7LLxqS5k29CiAVx0JSItqAPvX1ZvLMY2aq//MQMw
      0VFEx7Kt5aWNvKHTor9RUuuzwiZ5kwXt2vJt6bFiV7yS+EXofpFEmqyJP
      VJzyAFIXJRTv4k007n0M1UpXQpGjywECI6DbIhfBL8CsNskTCjrsfU+Tw
      RRkRKAbtJYughs9bDYkDu9UsKd/AE4zXk4prwo8/f1chpmzpHKOXiWzt+
      xaCj648I4rOjdI9s4JP8J0qwVKoLEMGeiZlf2UlaiyMzZYzTOxI03PHp1
      Whk6TXhnmMVPWGYjjelvE38gq/XynobbQRGEJdnnHzH7SrS27FmgRcnBO
      3QQUPJChVn7iBHmdui++GAxpHoGdS6nSo4kQ6d5u5rL/Ctcnwu0k+s0Xi
      ZMzOqp7L31xl1jvYUWIswLQYsIFoiejU3UTKzq/Cpd5MK+I8cwCM3aQ2c
      D08URTPgu+U92pnYqm3auptywyjGAU/hkZ13XN7YRhLk/kuX8QXo3tZdj
      dKA4f/uNf1DURpJK9004uCkxuAtu5HemMv7YPTTx9Ua2pZFW5O+k2Mf2Z
      F/geOvtNw7UV8wOT1nokXu9lnIZ9Xcs1cGGmRYE7jW15F07uGnMi1s2Gt
      LAST7t/PlTNZU6h0rVExErVa7T+VNidrgwGIke0YqYIwvTINRs+9VeJE3
      AJeatDlQs+01jrqqFWWmGmmsEBTTRuoDQHK7YBFFy4xIwQqZGW0EVre39
      OU5CL5LHIYiAVoV16YwiGd5WvFF8P1ZJK4ki8GFgYiMcPKmjQgP7DumqG
      n7eQtMD5tezTQeC07ntV3bi5pdznZHVcF2Kqg+qHjJQlhUdK7Pew3kq7k
      mfCdQV0BmQSYyjEAaTijaw4fAMxAbiw4OU0eNeU//zcpp04AuTFfJorIg
      oZ+iCTYei8HMUA9/ysLFXA64wdsuCj0zXmNiYwosisuNg3TXfoBOzohKq
      fkeXt

4. IANA Considerations 💅

okay so IANA has registered the media type application/cms in the Standards tree 🌈 It used the applications given in Section 2 of this document, so the paperwork is literally done ✨

IANA also set up two subtype registries, "CMS Encapsulating Content Types" and "CMS Inner Content Types" 🦋 New entries go through Expert Review [RFC5226]. The Expert decides whether something is an ECT or an ICT. The rule is that an ICT does not encapsulate another content type, while an ECT does 🫶

Here are the initial values. First, the encapsulating ones:

   CMS Encapsulating Content Types

   Name                        | Document | Object Identifier
   ----------------------------+----------+---------------------------
   authData                    |[RFC5652] | 1.2.840.113549.1.9.16.1.2
   compressedData              |[RFC3274] | 1.2.840.113549.1.9.16.1.9
   contentCollection           |[RFC4073] | 1.2.840.113549.1.9.16.1.19
   contentInfo                 |[RFC5652] | 1.2.840.113549.1.9.16.1.6
   contentWithAttrs            |[RFC4073] | 1.2.840.113549.1.9.16.1.20
   authEnvelopedData           |[RFC5083] | 1.2.840.113549.1.9.16.1.23
   encryptedKeyPkg             |[RFC6032] | 2.16.840.1.101.2.1.2.78.2
   digestData                  |[RFC5652] | 1.2.840.113549.1.9.16.1.5
   encryptedData               |[RFC5652] | 1.2.840.113549.1.9.16.1.6
   envelopedData               |[RFC5652] | 1.2.840.113549.1.9.16.1.3
   signedData                  |[RFC5652] | 1.2.840.113549.1.9.16.1.2

And now the inner content ones, which are a whole vibe 👑

   CMS Inner Content Types

   Name                        | Document | Object Identifier
   ----------------------------+----------+---------------------------
   firmwarePackage             |[RFC4108] | 1.2.840.113549.1.9.16.1.16
   firmwareLoadReceipt         |[RFC4108] | 1.2.840.113549.1.9.16.1.17
   firmwareLoadError           |[RFC4108] | 1.2.840.113549.1.9.16.1.18
   aKeyPackage                 |[RFC5958] | 2.16.840.1.101.2.1.2.78.5
   sKeyPackage                 |[RFC6031] | 1.2.840.113549.1.9.16.1.25
   trustAnchorList             |[RFC5914] | 1.2.840.113549.1.9.16.1.34
   TAMP-statusQuery            |[RFC5934] | 2.16.840.1.101.2.1.2.77.1
   TAMP-statusResponse         |[RFC5934] | 2.16.840.1.101.2.1.2.77.2
   TAMP-update                 |[RFC5934] | 2.16.840.1.101.2.1.2.77.3
   TAMP-updateConfirm          |[RFC5934] | 2.16.840.1.101.2.1.2.77.4
   TAMP-apexUpdate             |[RFC5934] | 2.16.840.1.101.2.1.2.77.5
   TAMP-apexUpdateConfirm      |[RFC5934] | 2.16.840.1.101.2.1.2.77.6
   TAMP-communityUpdate        |[RFC5934] | 2.16.840.1.101.2.1.2.77.7
   TAMP-communityUpdateConfirm |[RFC5934] | 2.16.840.1.101.2.1.2.77.8
   TAMP-seqNumAdjust           |[RFC5934] | 2.16.840.1.101.2.1.2.77.10
   TAMP-seqNumAdjustConfirm    |[RFC5934] | 2.16.840.1.101.2.1.2.77.11
   TAMP-error                  |[RFC5934] | 2.16.840.1.101.2.1.2.77.9
   keyPackageReceipt           |[RFC7191] | 2.16.840.1.101.2.1.2.78.3
   keyPackageError             |[RFC7191] | 2.16.840.1.101.2.1.2.78.6

5. Security Considerations 🔥

okay, this one is serious, bestie 😭 The security stuff is covered in the answers to the Security Considerations template questions, which you'll find in Section 2. Go read that, it's the main event 💀

6. Acknowledgments 🫶

Special thanks to Carl Wallace for generating the example in Section 3. The example is the real MVP here 👑

7. References 📚

7.1. Normative References

  • [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [RFC3274] Gutmann, P., "Compressed Data Content Type for Cryptographic Message Syntax (CMS)", RFC 3274, June 2002.
  • [RFC3370] Housley, R., "Cryptographic Message Syntax (CMS) Algorithms", RFC 3370, August 2002.
  • [RFC4021] Klyne, G. and J. Palme, "Registration of Mail and MIME Header Fields", RFC 4021, March 2005.
  • [RFC4073] Housley, R., "Protecting Multiple Contents with the Cryptographic Message Syntax (CMS)", RFC 4073, May 2005.
  • [RFC4108] Housley, R., "Using Cryptographic Message Syntax (CMS) to Protect Firmware Packages", RFC 4108, August 2005.
  • [RFC5083] Housley, R., "Cryptographic Message Syntax (CMS) Authenticated-Enveloped-Data Content Type", RFC 5083, November 2007.
  • [RFC5084] Housley, R., "Using AES-CCM and AES-GCM Authenticated Encryption in the Cryptographic Message Syntax (CMS)", RFC 5084, November 2007.
  • [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
  • [RFC5273] Schaad, J. and M. Myers, "Certificate Management over CMS (CMC): Transport Protocols", RFC 5273, June 2008.
  • [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, September 2009.
  • [RFC5753] Turner, S. and D. Brown, "Use of Elliptic Curve Cryptography (ECC) Algorithms in Cryptographic Message Syntax (CMS)", RFC 5753, January 2010.
  • [RFC5754] Turner, S., "Using SHA2 Algorithms with Cryptographic Message Syntax", RFC 5754, January 2010.
  • [RFC5914] Housley, R., Ashmore, S., and C. Wallace, "Trust Anchor Format", RFC 5914, June 2010.
  • [RFC5934] Housley, R., Ashmore, S., and C. Wallace, "Trust Anchor Management Protocol (TAMP)", RFC 5934, August 2010.
  • [RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, August 2010.
  • [RFC5959] Turner, S., "Algorithms for Asymmetric Key Package Content Type", RFC 5959, August 2010.
  • [RFC6031] Turner, S. and R. Housley, "Cryptographic Message Syntax (CMS) Symmetric Key Package Content Type", RFC 6031, December 2010.
  • [RFC6032] Turner, S. and R. Housley, "Cryptographic Message Syntax (CMS) Encrypted Key Package Content Type", RFC 6032, December 2010.
  • [RFC6033] Turner, S., "Algorithms for Cryptographic Message Syntax (CMS) Encrypted Key Package Content Type", RFC 6033, December 2010.
  • [RFC6160] Turner, S., "Algorithms for Cryptographic Message Syntax (CMS) Protection of Symmetric Key Package Content Types", RFC 6160, April 2011.
  • [RFC6161] Turner, S., "Elliptic Curve Algorithms for Cryptographic Message Syntax (CMS) Encrypted Key Package Content Type", RFC 6161, April 2011.
  • [RFC6162] Turner, S., "Elliptic Curve Algorithms for Cryptographic Message Syntax (CMS) Asymmetric Key Package Content Type", RFC 6162, April 2011.
  • [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, January 2013.
  • [RFC7191] Housley, R., "Cryptographic Message Syntax (CMS) Key Package Receipt and Error Content Types", RFC 7191, April 2014.

7.2. Informative References

  • [RFC2315] Kaliski, B., "PKCS #7: Cryptographic Message Syntax Version 1.5", RFC 2315, March 1998.
  • [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", RFC 5751, January 2010.

Authors' Addresses 💌

   Sean Turner
   IECA, Inc.
   3057 Nutley Street, Suite 106
   Fairfax, VA 22031
   USA

   EMail: turners@ieca.com
   Phone: +1.703.628.3180


   Russell Housley
   Vigil Security, LLC
   918 Spring Knoll Drive
   Herndon, VA 20170
   USA

   EMail: housley@vigilsec.com


   Jim Schaad
   Soaring Hawk Consulting

   EMail: ietf@augustcellars.com
📦 where this page comes from