rfc-3274

Compressed Data Content Type for Cryptographic Message Syntax (CMS)

P. Gutmann

date2002-06 streamIETF areasec wgsmime statusPROPOSED STANDARD pages6 canonicalhttps://www.rfc-editor.org/rfc/rfc3274 doi10.17487/RFC3274

This document defines a format for using compressed data as a Cryptographic Message Syntax (CMS) content type. Compressing data before transmission provides a number of advantages, including the elimination of data redundancy which could help an attacker, speeding up processing by reducing the amount of data to be processed by later steps (such as signing or encryption), and reducing overall message size. Although there have been proposals for adding compression at other levels (for example at the MIME or SSL level), these don't address the problem of compression of CMS content unless the compression is supplied by an external means (for example by intermixing MIME and CMS). [STANDARDS-TRACK]

Extracted elements (14)

design-rationale §3

Compressing data before encryption reduces known plaintext available to an attacker by eliminating data redundancy, thereby enhancing security provided by subsequent encryption steps.

security, crypto

design-rationale §1

Compression is defined at the CMS content layer rather than at MIME or SSL levels because those alternatives do not address compression of CMS content unless an external mechanism intermixes MIME and CMS.

security

design-rationale §2.1

ZLIB compression levels (ranging from good-but-slow to less-good-but-fast) need not be specified as algorithm parameters because any compression level is always compatible with the decompression algorithm.

security

interoperability-note §2.1

Due to a historical ambiguity when translating the 1988 AlgorithmIdentifier syntax to 1997 syntax, some implementations encode ZLIB null parameters as an ASN.1 NULL element while others omit them entirely. Implementations must be prepared to accept both encodings.

security

normative-requirement §1 SHOULD

CMS implementations SHOULD include support for the CompressedData content type.

security

normative-requirement §2 MUST

CMS implementations that support the CompressedData content type MUST include support for the ZLIB compression algorithm (RFC 1950, RFC 1951).

security

normative-requirement §1.1 SHOULD

Implementations SHOULD use the SMIMECapabilities attribute to indicate their ability to process compressed content types.

security

normative-requirement §1.1 MUST

The SMIMECapability SEQUENCE representing the ability to process content compressed with id-alg-zlibCompression MUST be DER-encoded as the hexadecimal string: 30 0D 06 0B 2A 86 48 86 F7 0D 01 09 10 03 08.

security

normative-requirement §1.1 MUST

The version field of CompressedData MUST be 0.

security

normative-requirement §2 SHOULD

The ZLIB algorithm parameters field SHOULD be encoded as omitted, but MAY be encoded as NULL.

security

protocol-element §1.1

The compressed-data content type is identified by OID id-ct-compressedData: { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) ct(1) 9 }.

security, registry

protocol-element §2

The ZLIB compression algorithm is identified by OID id-alg-zlibCompress: { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 8 }. This algorithm has no parameters.

security, registry

security-consideration §3

Combining security-sensitive material with possibly untrusted data before compression and encryption can leak information about the sensitive data, because an attacker who knows the untrusted data can infer information from the compression ratio.

security, crypto

wire-format §1.1

CompressedData is an ASN.1 SEQUENCE containing: version (CMSVersion, always 0), compressionAlgorithm (CompressionAlgorithmIdentifier), and encapContentInfo (EncapsulatedContentInfo) holding the compressed content.

security