Subject: Re: Compressed data type for S/MIME

From: [email-masked] (Peter Gutmann)
Date: Wed, 28 Jul 1999 12:31:17 (NZST)

Andrew Farrell <[email-masked]> writes:

>In message <[email-masked]>you write:
>>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.

>Jim Schaad brought this up about 14 months ago, 

Ah, I thought I'd seen it mentioned before somewhere, just couldn't remember
where.

>the consensus was that this made a lot more sense applied on a MIME level. 
>What actually happened next isn't recorded :)

Nothing happened, which is the problem with applying it on a MIME level - it's
never going to happen because you'd have to convince an infinite[0] number of
MUA's and MTA's to implement it (I present as exhibit 1 the fact that it's 
gone nowhere after 14 months).  Given that people are still using mailers 
dating from the stone age, and that there's no incentive to implement it (look
at how long it's taking to disable relaying and other spammer aids, which is 
probably the No.1 critical mail problem at the moment) it's never going to 
happen if you leave it at the MIME level.  In contrast putting it in CMS means
you automatically get it when you use CMS, so any new mailer which supports 
CMS would also support compression.  In contrast noone can afford to support it
at the MIME level because 99.999% of all implementations won't be able to do 
anything with it.  Technically it might make more sense at the MIME level, but
in practice all that putting it there is doing is guaranteeing that it'll never
eventuate.

On a related point, there's my standard refrain that CMS stands for 
Cryptographic Message Syntax, not MIME Bit-Bagging Scheme - having it at the
MIME level is of no use if you're using CMS without MIME.

Peter.

[0] Figures exaggerated slightly for effect.

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Tue, 27 Jul 1999 19:41:26 -0700

At 12:31 PM 7/28/1999 +0000, Peter Gutmann wrote:
>In contrast putting it in CMS means
>CMS would also support compression.

Except that there are already many S/MIME and other CMS protocols out there 
that will choke if they get this content type. I'm not saying it shouldn't 
be done, just that you shouldn't send it out for any S/MIME v3 messages. It 
would be good to have it in for other new CMS-using protocols, or for 
future versions of S/MIME.

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: Andrew Farrell <[email-masked]>
Date: Wed, 28 Jul 1999 03:49:46 +0100

Hmph.

Just like EncryptedData, I meant. Not EnvelopedData, which is more
widespread, of course.

Andrew.

---

From: Andrew Farrell <[email-masked]>
Date: Wed, 28 Jul 1999 03:40:40 +0100

>In contrast putting it in CMS means you automatically get it when you
>use CMS, so any new mailer which supports CMS would also support
>compression.

Just like EnvelopedData.

Also, you're not putting it in CMS, you're writing a supplmentary draft
to a RFC that going towards the light, so it'll be six months before you
can even get a draft of "CMS for S/MIME 4", which might make support of
CompressedData mandatory.

A solution I came up with the last time someone walked up to me and
asked me this (which works inside the current solidifying structure) is to
define new oids for "this compression followed by this encryption" and
"this compression followed by this hashing", but that run the obvious
problem that you end up with (# of hash algs + # of symmetric algs) * #
of compression algs new oids. I mention this only in passing. Now that I
think about it a bit more, having an oid for a CMS version of
compression which has as its parameters the alg of the hashing/symmetric
function might be worth a look, but it's very late, and I'm just typing
out loud :)

>MIME level is of no use if you're using CMS without MIME.

Point.

Andrew.