draft-ietf-smime-compression-06.txt   draft-ietf-smime-compression-07.txt 
Internet Draft Editor: Peter Gutmann Internet Draft Editor: Peter Gutmann
draft-ietf-smime-compression-06.txt University of Auckland draft-ietf-smime-compression-07.txt University of Auckland
August 30, 2001 November 11, 2001
Expires February 2002 Expires May 2002
Compressed Data Content Type for CMS Compressed Data Content Type for CMS
Status of this memo Status of this memo
This document is an Internet-Draft and is in full conformance with all This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026. provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Task Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other Force (IETF), its areas, and its working groups. Note that other
skipping to change at line 48 skipping to change at line 47
levels (for example at the MIME or SSL level) these don't address the levels (for example at the MIME or SSL level) these don't address the
problem of compression of CMS content unless the compression is problem of compression of CMS content unless the compression is
supplied by an external means (for example by intermixing MIME and supplied by an external means (for example by intermixing MIME and
CMS). This document defines a format for using compressed data as a CMS). This document defines a format for using compressed data as a
CMS content type. CMS content type.
1. Introduction 1. Introduction
This document describes a compressed data content type for CMS. This This document describes a compressed data content type for CMS. This
is implemented as a new ContentInfo type and is an extension to the is implemented as a new ContentInfo type and is an extension to the
types currently defined in CMS [RFC2630]. Future implementations of types currently defined in CMS [RFC2630]. CMS implementations SHOULD
CMS should include this extension. include support for the CompressedData content type.
The format of the messages are described in ASN.1 [ASN1]. The format of the messages are described in ASN.1 [ASN1].
The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT",
"RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be
interpreted as described in [RFC2119]. interpreted as described in [RFC2119].
1.1 Compressed Data Content Type 1.1 Compressed Data Content Type
The compressed-data content type consists of content of any type The compressed-data content type consists of content of any type
skipping to change at line 107 skipping to change at line 106
content compressed with the algorithm identified by id-alg- content compressed with the algorithm identified by id-alg-
zlibCompression MUST be DER-encoded as the following hexadecimal zlibCompression MUST be DER-encoded as the following hexadecimal
string: string:
30 0D 06 0B 2A 86 48 86 F7 0D 01 09 10 03 08 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). (but see also the implementation note in section 2.1).
2. Compression Types 2. Compression Types
CMS implementations SHOULD include ZLIB [RFC1950] [RFC1951], which is CMS implementations that support the CompressedData content type MUST
free of any intellectual property restrictions and has a freely- include support for the ZLIB compression algorithm [RFC1950] [RFC1951],
available, portable and efficient reference implementation. The which has a freely-available, portable and efficient reference
following object identifier identifies ZLIB: implementation. The following object identifier identifies ZLIB:
id-alg-zlibCompress OBJECT IDENTIFIER ::= { iso(1) member-body(2) id-alg-zlibCompress OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 8 } us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 8 }
This algorithm has no parameters. The parameters field SHOULD be This algorithm has no parameters. The parameters field SHOULD be
encoded as omitted, but MAY be encoded as NULL (see the implemenation encoded as omitted, but MAY be encoded as NULL (see the implemenation
note in section 2.1). note in section 2.1).
2.1. Implementation notes 2.1. Implementation notes
skipping to change at line 143 skipping to change at line 142
and some will omit them entirely (see for example section 12 of CMS and some will omit them entirely (see for example section 12 of CMS
[RFC2630]). Although the correct encoding is to omit the parameters [RFC2630]). Although the correct encoding is to omit the parameters
field, implementations may encounter encodings which use an ASN.1 NULL field, implementations may encounter encodings which use an ASN.1 NULL
element for the parameters. element for the parameters.
3. Security Considerations 3. Security Considerations
This RFC is not concerned with security, except for the fact that This RFC is not concerned with security, except for the fact that
compressing data before encryption can enhance the security provided by compressing data before encryption can enhance the security provided by
other processing steps by reducing the quantity of known plaintext other processing steps by reducing the quantity of known plaintext
available to an attacker. available to an attacker. However, implementations should be aware of
possible security threats of combining security sensitive material with
possibly untrusted data before the compression and encryption. This is
because information about the sensitive data may be inferred from
knowing the untrusted data and the compression ratio.
4. IANA Considerations 4. IANA Considerations
The CompressedData content type and compression algorithms are The CompressedData content type and compression algorithms are
identified by object identifiers (OIDs). OIDs were assigned from an identified by object identifiers (OIDs). OIDs were assigned from an
arc contributed to the S/MIME Working Group by the RSA Security. arc contributed to the S/MIME Working Group by RSA Security. Should
Should additional compression algorithms be introduced, the advocates additional compression algorithms be introduced, the advocates for such
for such algorithms are expected to assign the necessary OIDs from algorithms are expected to assign the necessary OIDs from their own
their own arcs. No action by the IANA is necessary for this document arcs. No action by the IANA is necessary for this document or any
or any anticipated updates. anticipated updates.
Author Address Author Address
Peter Gutmann Peter Gutmann
University of Auckland University of Auckland
Private Bag 92019 Private Bag 92019
Auckland, New Zealand Auckland, New Zealand
pgut001@cs.auckland.ac.nz pgut001@cs.auckland.ac.nz
References References
 End of changes. 

This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/