Skip to main content

The application/cms media type

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 7193.
Authors Sean Turner , Russ Housley , Jim Schaad
Last updated 2014-01-09 (Latest revision 2013-09-17)
RFC stream Internet Engineering Task Force (IETF)
Stream WG state (None)
Document shepherd Paul E. Hoffman
Shepherd write-up Show Last changed 2013-10-30
IESG IESG state Became RFC 7193 (Informational)
Consensus boilerplate Yes
Telechat date (None)
Responsible AD Stephen Farrell
Send notices to,,,,
IANA IANA review state IANA OK - Actions Needed
Internet Engineering Task Force (IETF)                         S. Turner
Internet Draft                                                      IECA
Intended Status: Informational                                R. Housley
Expires: March 21, 2014                                   Vigil Security
                                                               J. Schaad
                                                 Soaring Hawk Consulting
                                                      September 17, 2013

                     The application/cms media type


   This document registers the application/cms media types for use with
   the corresponding CMS (Cryptographic Message Syntax) content types.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

Copyright Notice

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

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   ( 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 Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.


Turner, Housley, & Schaad  Exp. Dec 24, 2013                    [Page 1]
Internet-Draft         application/cms Media Type     September 17, 2013

1. Introduction

   [RFC5751] registered the application/pkc7-mime media type.  That
   document defined five optional smime-type parameters.  The smime-type
   parameter originally conveyed details about the security applied
   (signed or enveloped) to the data content type, hence signed-data and
   enveloped-data, the name of the data, and was later expanded to also
   indicate that the message was compressed, compressed-data, and that
   the message is a certs-only message.  This document does not affect
   those registrations as this document places no requirements on S/MIME
   (Secure Multipurpose Internet Mail Extensions) agents.

   The registration done by the S/MIME documents was done assuming that
   there would be a MIME (Multipurpose Internet Mail Extensions)
   wrapping layer around each of the different enveloping contents, thus
   there was no need to include more than one item in each smime-type. 
   This is no longer the case with some of the more advanced enveloping
   types.  Some protocols such as the CMC (Certificate Management over
   Cryptographic Message Syntax) [RFC5273] have defined additional
   S/MIME types.  New protocols that intend to wrap MIME content should
   continue to define a smime-type string, however new protocols that
   intend to wrap non-mime types should use this mechanism instead.

   CMS (Cryptographic Message Syntax) [RFC5652] associates a content
   type identifier (OID) with a content; CMS content types have been
   widely used to define contents that can be enveloped using other CMS
   content types and to define enveloping content types some of which
   provide security services.  CMS protecting content types, those that
   provide security services, include: Signed Data [RFC5652], Enveloped
   Data [RFC5652], Digest Data [RFC5652], Encrypted Data [RFC5652],
   Authenticated Data [RFC5652], Authenticated Enveloped Data [RFC5083],
   and Encrypted Key Package [RFC6032].  CMS non-protecting content
   types, those that provide no security services but encapsulate other
   CMS content types, include: Content Information [RFC5652], Compressed
   Data [RFC3274], Content Collection [RFC4073], and Content With
   Attributes [RFC4073].  Then, there are the inner most content types
   that include: 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], id-ct-KP-keyPackageReceipt
   [ID.housley-keypackage-receipt-n-error], TAMP Status Query, TAMP
   Status Response, TAMP Update, TAMP Update Confirm, TAMP Apex Update,
   TAMP Apex Update Confirmation, TAMP Community Update Confirm, TAMP
   Sequence Adjust, TAMP Sequence Adjust Confirmation, TAMP Error
   [RFC5934], Key Package Error, and Key Package Receipt [ID.housley-

   To support conveying CMS content types, this document defines a media

Turner, Housley, & Schaad  Exp. Dec 24, 2013                    [Page 2]
Internet-Draft         application/cms Media Type     September 17, 2013

   type and parameters that indicate the enveloping and embedded CMS
   content types.

   New CMS content types should be affirmative in defining the string
   that identifies the new content type and should additionally define
   if the new content type is expected to appear in the
   encapsulatedContent or innerContent field.

1.1. Requirements Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in [RFC2119].

2. CMS Media Type Registration Applications

   This section provides the media type registration application for the
   application/cms media type (see [RFC6838], Section 5.6).

   Type name: application

   Subtype name: cms

   Required parameters: None.

   Optional parameters:

     encapsulatingContent=y; where y is one or more CMS ECT
     (Encapsulating Content Type) identifiers; multiple values are
     encapsulated in quotes and separated by a folding-whitespace comma
     folding-whitespace.  ECT values are based on content types found in
     [RFC3274], [RFC4073], [RFC5083], [RFC5652], and [RFC6032].  This
     list can later be extended, see Section 4.

     innerContent=x; where x is one or more CMS ICT (Inner Content Type)
     identifiers; multiple values encapsulated in quotes and are
     separated by a folding-whitespace comma folding-whitespace.  ICT

Turner, Housley, & Schaad  Exp. Dec 24, 2013                    [Page 3]
Internet-Draft         application/cms Media Type     September 17, 2013

     values are based on content types found in [RFC4108], [RFC5914],
     [RFC5934], [RFC5958], [RFC6031], and [ID.housley-keypackage-
     receipt-n-error].  This list can later be extended, see Section 4.

     id-data [RFC5652] MUST NOT be used if it is the only inner content
     listed and the data is MIME content;  when id-data is used to
     encapsulate MIME, the media type application/pkcs7-mime media type
     defined in [RFC5751] SHOULD be used.

     The optional parameters are case-sensitive.

   Encoding considerations:


     [RFC5652] requires that the outer most encapsulation be

   Security considerations:

     The following security considerations apply:

     RFC       | CMS Protecting Content Type and Algorithms
     [RFC3370] | signedData, envelopedData,  
     [RFC5652] | digestedData, encryptedData, and 
     [RFC5753] | authData
     [RFC5754] |

Turner, Housley, & Schaad  Exp. Dec 24, 2013                    [Page 4]
Internet-Draft         application/cms Media Type     September 17, 2013

     [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-status-query, tamp-status-response,
               | tamp-update, tamp-update-confirm,
               | tamp-apex-update,
               | tamp-apex-update-confirm,
               | tamp-community-update,
               | tamp-community-update-confirm,
               | tamp-sequence-adjust,
               | tamp-sequence-adjust-confirm, and
               | tamp-error
     [ID.housley-keypackage-receipt-n-error] |
               | keyPackageReceipt and keyPackageError

     In some circumstances, significant information can be leaked by
     disclosing what the innermost ASN.1 structure is.  In these cases
     it is acceptable to disclose the wrappers without disclosing the
     inner content type.

     ASN.1 encoding rules (e.g., DER and BER) have a type-length-value
     structure, and it is easy to construct malicious content with
     invalid length fields that can cause buffer overrun conditions.
     ASN.1 encoding rules allows for arbitrary levels of nesting, which

Turner, Housley, & Schaad  Exp. Dec 24, 2013                    [Page 5]
Internet-Draft         application/cms Media Type     September 17, 2013

     may make it possible to construct malicious content that will cause
     a stack overflow. Interpreters of 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.

   Interoperability considerations:

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

     In all cases, CMS content types are encapsulated within ContentInfo
     structures [RFC5652]; that is the outer most enveloping structure
     is ContentInfo.

     When processing a SignedData around any of the inner content type
     the [RFC5652] validation rules MUST be used.  The PKCS #7 [RFC2315]
     validation rules MUST NOT be used.

     The Content-Type header field of all application/cms objects SHOULD
     include the optional "encapsulatingContent" and "innerContent"

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

   Published specification: This specification.

   Applications which use this media type:

     Applications that support CMS (Cryptographic Message Syntax)
     content types.

   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 <>

   Restrictions on usage: none

   Author: Sean Turner <>


Turner, Housley, & Schaad  Exp. Dec 24, 2013                    [Page 6]
Internet-Draft         application/cms Media Type     September 17, 2013

   Intended usage: COMMON

   Change controller: The IESG <>

3.  Example

   The following is an example encrypted status response message:

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


4.  IANA Considerations


Turner, Housley, & Schaad  Exp. Dec 24, 2013                    [Page 7]
Internet-Draft         application/cms Media Type     September 17, 2013

   IANA is asked to register the media type application/cms in the
   Standards tree using the applications provided in Section 2 of this

   IANA is also asked to establish two subtype registries called "CMS
   Encapsulating Content Types" and "CMS Inner Content Types".  Entries
   in these registries is by Expert Review [RFC5226].  The Expert will
   determine whether the content is an ECT or an ICT; where the rule is
   that an ICT does not encapsulate another content type while an ECT
   does encapsulate another content type.

   Initial values are as follows:

   CMS Encapsulating Content Types

   Name                        | Document | Object Identifier
   authData                    |[RFC5652] | 1.2.840.113549.
   compressedData              |[RFC3274] | 1.2.840.113549.
   contentCollection           |[RFC4073] | 1.2.840.113549.
   contentInfo                 |[RFC5652] | 1.2.840.113549.
   contentWithAttrs            |[RFC4073] | 1.2.840.113549.
   authEnvelopedData           |[RFC5083] | 1.2.840.113549.
   encryptedKeyPkg             |[RFC6030] | 2.16.840.
   digestData                  |[RFC5652] | 1.2.840.113549.
   encryptedData               |[RFC5652] | 1.2.840.113549.
   envelopedData               |[RFC5652] | 1.2.840.113549.
   signedData                  |[RFC5652] | 1.2.840.113549.

   CMS Inner Content Types

   Name                        | Document | Object Identifier
   firmwarePackage             |[RFC4108] | 1.2.840.113549.
   firmwareLoadReceipt         |[RFC4108] | 1.2.840.113549.
   firmwareLoadError           |[RFC4108] | 1.2.840.113549.
   aKeyPackage                 |[RFC5958] | 2.16.840.
   sKeyPackage                 |[RFC6031] | 1.2.840.113549.
   trustAnchorList             |[RFC5914] | 1.2.840.113549.
   TAMP-statusQuery            |[RFC5934] | 2.16.840.
   TAMP-statusResponse         |[RFC5934] | 2.16.840.
   TAMP-update                 |[RFC5934] | 2.16.840.
   TAMP-updateConfirm          |[RFC5934] | 2.16.840.
   TAMP-apexUpdate             |[RFC5934] | 2.16.840.
   TAMP-apexUpdateConfirm      |[RFC5934] | 2.16.840.
   TAMP-communityUpdate        |[RFC5934] | 2.16.840.
   TAMP-communityUpdateConfirm |[RFC5934] | 2.16.840.
   TAMP-seqNumAdjust           |[RFC5934] | 2.16.840.

Turner, Housley, & Schaad  Exp. Dec 24, 2013                    [Page 8]
Internet-Draft         application/cms Media Type     September 17, 2013

   TAMP-seqNumAdjustConfirm    |[RFC5934] | 2.16.840.
   TAMP-error                  |[RFC5934] | 2.16.840.
   keyPackageReceipt           |[ID.housley-keypackage-receipt-n-error]
                                          | 2.16.840.
   keyPackageError             |[ID.housley-keypackage-receipt-n-error]
                                          | 2.16.840.

5. Security Considerations

   See the answer to the Security Considerations template questions in
   Section 2.

6. Acknowledgments

   Special thanks to Carl Wallace for generating the example in Section

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

Turner, Housley, & Schaad  Exp. Dec 24, 2013                    [Page 9]
Internet-Draft         application/cms Media Type     September 17, 2013

              IANA Considerations Section in RFCs", 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

   [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

Turner, Housley, & Schaad  Exp. Dec 24, 2013                   [Page 10]
Internet-Draft         application/cms Media Type     September 17, 2013

              Message Syntax (CMS) Asymmetric Key Package Content Type",
              RFC 6162, April 2012.

   [RFC6838]  Freed, N., Klensin, J., and T. Hansen, "Media Type
              Specifications and Registration Procedures", BCP 13, RFC
              6838, January 2013.

   [ID.housley-keypackage-receipt-n-error] Housley, R., "Cryptographic
              Message Syntax (CMS) Key Package Receipt and Error Content
              Types", draft-housley-ct-keypackage-receipt-n-error, June

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

   Phone: +1.703.628.3180

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


   Jim Schaad
   Soaring Hawk Consulting


Turner, Housley, & Schaad  Exp. Dec 24, 2013                   [Page 11]