Peter Gutmann wrote:
Jim Schaad brought this up about 14 months ago,
Ah, I thought I'd seen it mentioned before somewhere, just couldn't remember
where.
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 :)
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.
Point.
Andrew.