rfc-4073

Protecting Multiple Contents with the Cryptographic Message Syntax (CMS)

R. Housley
date2005-05 streamIETF wgnon working group statusPROPOSED STANDARD pages9 canonicalhttps://www.rfc-editor.org/rfc/rfc4073 doi10.17487/RFC4073 errataview
This document describes a convention for using the Cryptographic Message Syntax (CMS) to protect a content collection. If desired, attributes can be associated with the content. [STANDARDS-TRACK]

Extracted elements (10)

design-rationale §1

The content-collection content type was introduced for use in exclusively ASN.1 environments where MIME multipart is unavailable. When CMS is used with MIME, multipart provides a widely deployed mechanism that makes this convention unnecessary.

pkix, crypto

normative-requirement §4 MUST

Implementations MUST be prepared to handle multiple levels of encapsulation, since a content collection may include both CMS protection content types and unprotected content types at varying protection levels.

pkix, crypto, security

normative-requirement §2 SHOULD

Implementations SHOULD also be prepared to handle the object identifier for the CompressedData content type (RFC 3274) within a ContentCollection.

pkix, crypto

normative-requirement §2 SHOULD

Implementations SHOULD be prepared to handle object identifiers for the SignedData, EncryptedData, EnvelopedData, and AuthenticatedData CMS content types within a ContentCollection.

pkix, crypto, security

protocol-element §2

The content-collection content type (id-ct-contentCollection) is identified by OID { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) ct(1) 19 } and transfers one or more content items, each identified by a content type.

pkix, crypto, security

protocol-element §3

The content-with-attributes content type (id-ct-contentWithAttrs) is identified by OID { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) ct(1) 20 } and associates a single ContentInfo with one or more attributes.

pkix, crypto, security

registry §2

This document assigns two S/MIME content type OIDs: id-ct-contentCollection (smime ct 19) and id-ct-contentWithAttrs (smime ct 20), under the existing PKCS#9/S/MIME arc. No new IANA registry is created.

registry, pkix, crypto

security-consideration §4

A content collection accommodates varying levels of protection; it is expected to be encapsulated in one or more CMS protecting content types, but this is not required. Implementations must therefore handle multiple encapsulation levels and the security considerations of [CMS] apply.

security, crypto, pkix

wire-format §2

ContentCollection is encoded as SEQUENCE SIZE (1..MAX) OF ContentInfo, where each ContentInfo carries a contentType OID and the associated content value.

pkix, crypto

wire-format §3

ContentWithAttributes is encoded as a SEQUENCE containing a single ContentInfo followed by SEQUENCE SIZE (1..MAX) OF Attribute; at least one attribute must be present.

pkix, crypto