RFC 3274 (rfc3274) - Page 2 of 6
Compressed Data Content Type for Cryptographic Message Syntax (CMS)
Alternative Format: Original Text Document
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 [RFC 2119].
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:
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 [RFC 2630], section
10.2.5.
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 [RFC 2630],
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 [RFC 2633], 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