Internet Engineering Task Force (IETF) S. Turner Request for Comments: 7193 IECA Category: Informational R. Housley ISSN: 2070-1721 Vigil Security J. Schaad 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.
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 mechanism instead.
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].
Turner, et al. Informational [Page 2]
RFC 7193 application/cms Media Type April 2014
To support conveying CMS content types, this document defines a media 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 parameter.
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.
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.
IANA has registered the media type application/cms in the Standards tree using the applications provided in Section 2 of this document.
Turner, et al. Informational [Page 8]
RFC 7193 application/cms Media Type April 2014
IANA has established two subtype registries called "CMS Encapsulating Content Types" and "CMS Inner Content Types". Entries in these registries are allocated 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.