Compressed Data Content Type for Cryptographic Message Syntax (CMS)
RFC 3274

Document Type RFC - Proposed Standard (June 2002; No errata)
Last updated 2013-03-02
Stream IETF
Formats plain text pdf html bibtex
Stream WG state (None)
Document shepherd No shepherd assigned
IESG IESG state RFC 3274 (Proposed Standard)
Consensus Boilerplate Unknown
Telechat date
Responsible AD Jeffrey Schiller
IESG note Approved
Responsible: RFC Editor
Send notices to <>, <>
Network Working Group                                         P. Gutmann
Request for Comments: 3274                        University of Auckland
Category: Standards Track                                      June 2002

                   Compressed Data Content Type for
                   Cryptographic Message Syntax (CMS)

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2002).  All Rights Reserved.


   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).

1. Introduction

   This document describes a compressed data content type for CMS.  This
   is implemented as a new ContentInfo type and is an extension to the
   types currently defined in CMS [RFC2630].  CMS implementations SHOULD
   include support for the CompressedData content type.

   The format of the messages are described in ASN.1 [ASN1].

Gutmann                     Standards Track                     [Page 1]
RFC 3274          Compressed Data Content Type for CMS         June 2002

   The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT",
   "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be
   interpreted as described in [RFC2119].

1.1 Compressed Data Content Type

   The compressed-data content type consists of content of any type,
   compressed using a specified algorithm.  The following object
   identifier identifies the compressed-data content type:

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

   The compressed-data content type shall have ASN.1 type

      CompressedData ::= SEQUENCE {
        version CMSVersion,
        compressionAlgorithm CompressionAlgorithmIdentifier,
        encapContentInfo EncapsulatedContentInfo

   The fields of type CompressedData have the following meanings:

      version is the syntax version number.  It MUST be 0.  Details of
      the CMSVersion type are discussed in CMS [RFC2630], section

      compressionAlgorithm is a compression algorithm identifier, as
      defined in section 2.

      encapContentInfo is the content which is compressed.  Details of
      the EncapsulatedContentInfo type are discussed in CMS [RFC2630],
      section 5.2.

   Implementations SHOULD use the SMIMECapabilities attribute to
   indicate their ability to process compressed content types.  Details
   of SMIMECapabilities are discussed in MSG [RFC2633], section 2.5.2.

   A compression SMIMECapability consists of the AlgorithmIdentifier for
   the supported compression algorithm.  In the case of the algorithm
   specified in this document, this is id-alg-zlibCompression, as
   specified in section 2.  Alternatively, the use of compression may be
   handled by prior arrangement (for example as part of an
   interoperability profile).

Gutmann                     Standards Track                     [Page 2]
RFC 3274          Compressed Data Content Type for CMS         June 2002

   The SMIMECapability SEQUENCE representing the ability to process
   content compressed with the algorithm identified by id-alg-
   zlibCompression MUST be DER-encoded as the following hexadecimal

      30 0D 06 0B 2A 86 48 86 F7 0D 01 09 10 03 08

   (but see also the implementation note in section 2.1).

2. Compression Types

   CMS implementations that support the CompressedData content type MUST
   include support for the ZLIB compression algorithm [RFC1950]
   [RFC1951], which has a freely-available, portable and efficient
   reference implementation.  The following object identifier identifies

      id-alg-zlibCompress OBJECT IDENTIFIER ::= { iso(1) member-body(2)
        us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 8 }

   This algorithm has no parameters.  The parameters field SHOULD be
   encoded as omitted, but MAY be encoded as NULL (see the
   implementation note in section 2.1).
Show full document text