Internet Engineering Task Force (IETF) S. Turner
Request for Comments: 7193 IECA
Category: Informational R. Housley
ISSN: 2070-1721 Vigil Security
Soaring Hawk Consulting
April 2014 The application/cms Media Type
This document registers the application/cms media type for use with
the corresponding CMS (Cryptographic Message Syntax) content types.
Status of This Memo
This document is not an Internet Standards Track specification; it is
published for informational purposes.
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). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
Copyright (c) 2014 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
(http://trustee.ietf.org/license-info) 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.
[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 to
the data content type, indicating whether it was signed or enveloped,
as well as the name of the data content; it was later expanded to
indicate whether the data content is compressed and whether the data
content contained 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
CMS (Cryptographic Message Syntax) [RFC5652] associates a content
type identifier (OID) with specific 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], Digested-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 innermost
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], 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 support conveying CMS content types, this document defines a media
type and parameters that indicate the enveloping and embedded CMS
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 parameter.
1.1. Requirements Terminology
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].
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.
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, a
comma, and 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, a comma, and folding-whitespace. ICT values
are based on content types found in [RFC4108], [RFC5914], [RFC5934],
[RFC5958], [RFC6031], and [RFC7191]. This list can later be
extended; see Section 4.
The optional parameters are case sensitive.
[RFC5652] requires that the outermost encapsulation be
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
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.
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 outermost enveloping
structure is ContentInfo.
CMS [RFC5652] defines slightly different processing rules for
SignedData than does PKCS #7 [RFC2315]. This media type employs
the CMS processing rules.
The Content-Type header field of all application/cms objects
SHOULD include the optional "encapsulatingContent" and
The Content-Disposition header field [RFC4021] can also be
included along with Content-Type's optional name parameter.
Published specification: This specification.
Applications that use this media type:
Applications that support CMS (Cryptographic Message Syntax)
Fragment identifier considerations: N/A
Magic number(s): None
File extension(s): .cmsc
Macintosh File Type Code(s):
Person & email address to contact for further information:
Sean Turner <email@example.com>
Intended usage: COMMON
Restrictions on usage: none
Author: Sean Turner <firstname.lastname@example.org>
Change controller: The IESG <email@example.com>
The following is an example encrypted status response message:
Content-Type: application/cms; encapsulatingContent=encryptedData;
4. IANA Considerations
IANA has registered the media type application/cms in the Standards
tree using the applications provided in Section 2 of this document.
5. Security Considerations
See the answer to the Security Considerations template questions in
Special thanks to Carl Wallace for generating the example in
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,
[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,
[RFC5273] Schaad, J. and M. Myers, "Certificate Management over CMS
(CMC): Transport Protocols", RFC 5273, June 2008.
[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
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.
3057 Nutley Street, Suite 106
Fairfax, VA 22031
Vigil Security, LLC
918 Spring Knoll Drive
Herndon, VA 20170
Soaring Hawk Consulting