Peter,
I don't know zlib from a zebra, but way back in the PEM days I argued for the
same sort of thing. The use of encryption obviously makes the use of
statistical
modems, and other bandwidth-efficiency devices essentially impossible, and
so it is essential to compress the plaintext before encrypting it.
But a question. Rather than inventing a new CMS data type, couldn't this be
implemented as a new encryption algorithm, such as zlib-with-triple-DES?
I certainly understand that an independent wrapping mechanism would provide
more generality, but I am a little concerned that CMS may not be as widely
adopted
as some might hope, whereas implementing it within a crypto algorithm would
allow
SSL, TLS, PSEC, etc., etc., to implement it within their suite of supported
algorithms.
Just a thought.
Also, don't some/most compression algorithms make use of previously calculated
symbol tables? Couldn't those tables be transferred and referred to
independently,
rather than being sent with the text, assuming they are reasonably constant?
This might argue that some parameters to the compression algorithm wold be nice
to have.
Bob
Peter Gutmann <pgut001(_at_)cs(_dot_)aucKland(_dot_)ac(_dot_)nz> 07/28/99
11:16AM >>>
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 <ietf-smime-request(_at_)imc(_dot_)org> 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
pgut001(_at_)cs(_dot_)auckland(_dot_)ac(_dot_)nz
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]