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



