RFC 4073

Protecting Multiple Contents with the Cryptographic Message Syntax (CMS)

πŸ“… published May 2005, from ietf

RFC 4073: Protecting Multiple Contents with the Cryptographic Message Syntax (CMS) πŸŽ€

  • Network Working Group 🌸
  • Request for Comments: 4073 πŸ“„
  • Author: R. Housley, Vigil Security πŸ’…
  • Category: Standards Track ✨
  • Date: May 2005 πŸ¦‹
  • Obsoletes or updates: nothing is listed in this doc πŸ’œ

Status of This Memo ✨

okay so this is an Internet standards track protocol for the internet community, and it's literally asking for discussion and suggestions for improvements 🫢 For the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 🌈

Copyright (C) The Internet Society (2005). ©️

Abstract πŸ¦‹

this doc is all about a convention for using the Cryptographic Message Syntax (CMS) to protect a content collection πŸŽ€ And if you want, you can associate attributes with the content too ✨

1. Introduction 🌸

so this doc describes that same convention for using CMS [CMS] to protect a content collection πŸ“¦ The content-collection content type is used to transfer one or more contents, each one identified by a content type. If you want, the content-with-attributes content type can be used to attach arbitrary attributes to the content 🏷️

okay, so this convention isn't needed when CMS is used with MIME [MSG]. MIME multipart [MIME] is already a straightforward, widely deployed way to carry more than one content item, each one tied to a MIME type πŸ’…

BUT CMS isn't always used with MIME πŸ‘€ Sometimes it's used in an exclusively ASN.1 [ASN1] environment. In that case, the content-collection content type is how you gather more than one content item, each one with an object identifier that specifies its content type 🧚

In this document, the key words MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL are to be interpreted as described in [STDWORDS]. πŸ“–

1.1. Content Collection Example πŸ“

this section gives one simple example to show why the content-collection content type exists πŸ’­ Picture an art collector who wants to sell one of his pieces, an ancient Greek urn called an amphora 🏺 The collector wants to compose a digitally signed offer for sale, and it has three parts. The first part is the owner's offer for sale, including the asking price. The second part is a high-quality image of the amphora. The final part is an appraisal from a well-respected ceramics expert, and the expert digitally signs that part. Figure 1 shows the structure, and the CMS SignedData content type is used for the two digital signatures πŸ”₯

+---------------------------------------------------------+
|                                                         |
| ContentInfo                                             |
|                                                         |
| +-----------------------------------------------------+ |
| |                                                     | |
| | SignedData                                          | |
| |                                                     | |
| | +-------------------------------------------------+ | |
| | |                                                 | | |
| | | ContentCollection                               | | |
| | |                                                 | | |
| | | +-----------+ +-----------+ +-----------------+ | | |
| | | |           | |           | |                 | | | |
| | | | Owner's   | | Image     | | SignedData      | | | |
| | | | Offer to  | | of the    | |                 | | | |
| | | | Sell the  | | Amphora   | | +-------------+ | | | |
| | | | Amphora   | |           | | |             | | | | |
| | | |           | |           | | | Appraisal   | | | | |
| | | |           | |           | | | of Ceramics | | | | |
| | | |           | |           | | | Expert      | | | | |
| | | |           | |           | | |             | | | | |
| | | |           | |           | | +-------------+ | | | |
| | | |           | |           | |                 | | | |
| | | +-----------+ +-----------+ +-----------------+ | | |
| | |                                                 | | |
| | +-------------------------------------------------+ | |
| |                                                     | |
| +-----------------------------------------------------+ |
|                                                         |
+---------------------------------------------------------+

Figure 1. Sample use of the ContentCollection Content Type 🎨

1.2. Content with Attributes Example 🌈

this one shows why the content-with-attributes content type exists 🧸 It's the same art collector, but now instead of one image, they provide several images. To help potential buyers, they attach several attributes to each image. The attributes give info about the image's resolution, the date it was taken, the photographer, and so on. Figure 2 shows the collection of images, with only two images and three attributes each. This entire image content collection could be carried instead of the single image from Figure 1, which lets it be covered by the collector's digital signature πŸ’…

+----------------------------------------------------------+
|                                                          |
| ContentCollection                                        |
|                                                          |
| +-------------------------+  +-------------------------+ |
| |                         |  |                         | |
| | ContentWithAttributes   |  | ContentWithAttributes   | |
| |                         |  |                         | |
| | +---------------------+ |  | +---------------------+ | |
| | |                     | |  | |                     | | |
| | | First Image of      | |  | | Second Image of     | | |
| | | the Amphora         | |  | | the Amphora         | | |
| | |                     | |  | |                     | | |
| | |                     | |  | |                     | | |
| | +---------------------+ |  | +---------------------+ | |
| |                         |  |                         | |
| | +---------------+       |  | +---------------+       | |
| | |               |       |  | |               |       | |
| | | Attribute 1   |       |  | | Attribute 1   |       | |
| | |               +--+    |  | |               +--+    | |
| | +-+-------------+  |    |  | +-+-------------+  |    | |
| |   | Attribute 2    |    |  |   | Attribute 2    |    | |
| |   |                +--+ |  |   |                +--+ | |
| |   +-+--------------+  | |  |   +-+--------------+  | | |
| |     | Attribute 3     | |  |     | Attribute 3     | | |
| |     |                 | |  |     |                 | | |
| |     +-----------------+ |  |     +-----------------+ | |
| |                         |  |                         | |
| +-------------------------+  +-------------------------+ |
|                                                          |
+----------------------------------------------------------+

Figure 2. Sample use of the ContentWithAttributes Content Type 🧁

2. Content Collection Content Type πŸ’œ

the content-collection content type is for transferring a collection of content items, each identified by a content type πŸ“¦ The syntax can handle contents with different levels of protection. For example, one content collection could include CMS protection content types as well as unprotected content types πŸ‘€ A content collection is expected to be encapsulated in one or more CMS protecting content types, but this specification doesn't require it.

here's the object identifier that names the content collection content type πŸ”’

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

and here's the syntax for the content-collection content 🧩

   ContentCollection ::= SEQUENCE SIZE (1..MAX) OF ContentInfo

The ContentCollection is a sequence of ContentInfo, one for each content in the collection. ContentInfo is defined in CMS. The contentType object identifier inside the ContentInfo tells you what type of content it is. Implementations of this specification SHOULD be prepared to handle object identifiers for the SignedData, EncryptedData, EnvelopedData, and AuthenticatedData content types, as specified in [CMS]. Implementations of this specification SHOULD also be prepared to handle the object identifier for the CompressedData content type, as specified in [COMPRESS]. 🫧

3. Content-with-Attributes Content Type πŸ¦‹

the content-with-attributes content type transfers a single content, which is identified by a content type, plus a collection of attributes associated with that content. The syntax accommodates an arbitrary number of attributes; however, there must be at least one attribute. ⭐

here's the object identifier that names the content-with-attributes content type πŸ”’

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

and here's the syntax for the content-with-attributes content 🧩

   ContentWithAttributes ::= SEQUENCE {
       content     ContentInfo,
       attrs       SEQUENCE SIZE (1..MAX) OF Attribute }

The ContentWithAttributes is a sequence of a single ContentInfo item, followed by a sequence of attributes. ContentInfo is defined in CMS. The contentType object identifier inside the ContentInfo indicates the type of the content. The Attribute structure was originally defined in X.501 [X501], and the definition is repeated in CMS. πŸŽ€

4. Security Considerations πŸ”

okay, this part is serious, bestie πŸ’€ The content-collection content type transfers one or more contents, each identified by a content type. The syntax accommodates contents with varying levels of protection. For example, a content collection could include CMS protection content types as well as unprotected content types. A content collection is expected to be encapsulated in one or more CMS protecting content types, but this is not required by this specification. As a result, implementations MUST be prepared to handle multiple levels of encapsulation. 🚨

The security considerations discussed in [CMS] are relevant when CMS is used to protect more than one content by making use of the content collection content type or content with attributes content type. πŸ›‘οΈ

5. References πŸ“š

5.1. Normative References πŸ”—

  • [ASN1] CCITT. Recommendation X.208: Specification of Abstract Syntax Notation One (ASN.1). 1988.
  • [COMPRESS] Gutmann, P., "Compressed Data Content Type for Cryptographic Message Syntax (CMS)", RFC 3274, June 2002.
  • [CMS] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852, July 2004.
  • [STDWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

5.2. Informative References πŸ“š

These are the bonus reads, bestie πŸŽ€ Not normative, just really good context.

  • [MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996. πŸ’Œ
  • [MSG] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004. πŸ”
  • [X501] CCITT. Recommendation X.501: The Directory -- Models. 1988. πŸ—‚οΈ

Appendix A: ASN.1 Module 🧩

Okay so this appendix is the ASN.1 module, and it has every structure you need to actually implement this spec πŸ’… It's meant to be used together with the ASN.1 modules in [CMS] and [COMPRESS], so keep those open too, periodt ✨

ContentCollectionModule
  { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
    pkcs-9(9) smime(16) modules(0) 26 }

DEFINITIONS IMPLICIT TAGS ::=
BEGIN

IMPORTS
  Attribute, ContentInfo
    FROM CryptographicMessageSyntax2004 -- [CMS]
      { iso(1) member-body(2) us(840) rsadsi(113549)
        pkcs(1) pkcs-9(9) smime(16) modules(0) cms-2001(14) };


-- Content Collection Content Type and Object Identifier

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

ContentCollection ::= SEQUENCE SIZE (1..MAX) OF ContentInfo

-- Content With Attributes Content Type and Object Identifier

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

ContentWithAttributes ::= SEQUENCE {
    content     ContentInfo,
    attrs       SEQUENCE SIZE (1..MAX) OF Attribute }

END

Author's Address 🏑

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

EMail: housley@vigilsec.com

Copyright (C) The Internet Society (2005). 🌈

This document is subject to the rights, licenses and restrictions in BCP 78, and except as set forth there, the authors keep all their rights πŸ’œ

This document and the information in it are provided on an "AS IS" basis. The contributor, the organization they represent or are sponsored by (if any), the Internet Society, and the Internet Engineering Task Force all disclaim all warranties, express or implied. That includes, but isn't limited to, any warranty that using the information won't infringe any rights, and any implied warranties of merchantability or fitness for a particular purpose. No cap, that's a lot of disclaimers 😭

Intellectual Property πŸ”

The IETF doesn't take a position on whether any Intellectual Property Rights or other rights claimed to cover the technology in this document are valid or how far they reach. It also doesn't say whether any license under those rights is or isn't available, and it hasn't made any independent effort to find such rights πŸ™ˆ If you want info on how rights work for RFC documents, check BCP 78 and BCP 79.

Copies of IPR disclosures sent to the IETF Secretariat, any assurances of licenses to be made available, and the results of any attempt to get a general license or permission for implementers or users are available from the IETF online IPR repository at http://www.ietf.org/ipr. πŸ“œ

The IETF invites anyone who knows about copyrights, patents, patent applications, or other proprietary rights that might cover technology needed to implement this standard to let them know. Send that info to the IETF at ietf-ipr@ietf.org 🫢

Acknowledgement 🌸

Funding for the RFC Editor function is currently provided by the Internet Society. Thank you, Internet Society πŸ“

πŸ“¦ where this page comes from