Subject: Compressed data type for S/MIME

From: [email-masked] (Peter Gutmann)
Date: Wed, 28 Jul 1999 11:16:07 (NZST)

From the "Why on earth hasn't anyone done this before?" department: I've just
spent the last hour or so adding zlib-based compression to an existing S/MIME 
implementation.  All this needs to work is a new content type, CompressedData.
Compressing data before processing has so many advantages (eliminates known
plaintext, speeds up processing by slow crypto algorithms, and reduces message
size, especially for the sorts of things you'd typically want to protect
(spreadsheets, documents, etc)) and implementing it with zlib is such a no-
brainer that I don't know why noone's looked at this before.  What do people 
think of the following as a new S/MIME draft?

Peter.

-- Snip --

Internet Draft                                      Editor: Peter Gutmann
draft-ietf-smime-compression-00.txt                 University of Auckland
July 20, 1999
Expires January 2000

                   Compressed Data Content Type for S/MIME

Status of this memo

This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026.

Internet-Drafts are working documents of the Internet Engineering Task Force
(IETF), its areas, and its working groups.  Note that other groups may also
distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months and may
be updated, replaced, or obsoleted by other documents at any time.  It is
inappropriate to use Internet- Drafts as reference material or to cite them
other than as "work in progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

Abstract

The Cryptographic Message Syntax data format doesn't currently contain any
provisions for compressing data before processing it.  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.  This document defines a format for using
compressed data as a CMS content type.

This draft is being discussed on the "ietf-smime" mailing list.  To join the
list, send a message to <[email-masked]> with the single word
"subscribe" in the body of the message.  Also, there is a Web site for the
mailing list at <http://www.imc.org/ietf-smime>.

1. Introduction

This document describes a compressed data content encryption type for S/MIME.
This is implemented as a new ContentInfo type and is an extension to the types
currently defined in CMS [CMS].

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

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) 3 }

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 shall be 0.

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

    encapContentInfo is the content which is compressed.

2. Compression Types

CMS implementations should include ZLIB [RFC 1950] [RFC 1951], which is free of
any intellectual property restrictions and has a freely-available, portable and
efficient reference implementation.  The following object identifier identifies
ZLIB:

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

The parameters for this algorithm are NULL.

3. Security Considerations

This RFC is not concerned with security, except for the fact that compressing
data before encryption can enhance the security provided by other processing
steps by reducing the quantity of known plaintext available to an attacker.

Author Address

Peter Gutmann
University of Auckland
Private Bag 92019
Auckland, New Zealand
[email-masked]

References

  ASN1  Recommendation X.680: Specification of Abstract Syntax Notation
        One (ASN.1), 1994.

  CMS   Cryptographic Message Syntax, draft-ietf-smime-cms-11.txt, Russ
        Housley, April 1999.

  RFC2119 Key Words for Use in RFC's to Indicate Requirement Levels,
        S.Bradner, March 1997.

  RFC1950 ZLIB Compressed Data Format Specification version 3.3, P.Deutsch and
        J-L Gailly, May 1996.

  RFC1951 DEFLATE Compressed Data Format Specification version 1.3, P.Deutsch,
        May 1996.

Appendix A: ASN.1 Module

PasswordRecipientInfo
  { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
    modules(0) compression(n+1) }

DEFINITIONS IMPLICIT TAGS ::=
BEGIN

CompressedData ::= SEQUENCE {
  version CMSVersion,       -- Always set to 0
  compressionAlgorithm CompressionAlgorithmIdentifier,
  encapContentInfo EncapsulatedContentInfo
  }

CompressionAlgorithmIdentifer ALGORITHM-IDENTIFIER ::= {
  { SYNTAX NULL IDENTIFIED BY id-alg-ZLIB },
  ...
  }

END

Full Copyright Statement

[etc]

---

From: Andrew Farrell <[email-masked]>
Date: Wed, 28 Jul 1999 00:42:14 +0100

>Peter.

Jim Schaad brought this up about 14 months ago, and the consensus was
that this made a lot more sense applied on a MIME level. What actually
happened next isn't recorded :)

Andrew.