My $0.02 to this debate.
SSL/TLS has built in compression support as part of the protocol, but this
has been slow to come to market. Why? One of the reasons has been that
you want to turn compression on and off depending on the underlying content
(e.g. if it is a GIF or JPG or .gz etc, don't compress). This has lead at
least some people to form the opinion that compression doesn't really
belong in a crypto protocol, but at the application layer where the
information to make these sort of decisions is available.
Now of course the situation in S/MIME is somewhat different to SSL/TLS, as
you can be less concerned about the CPU wastage of compressing stuff that
is already compressed as a client is generally just decoding messages one
at a time (an exception to this is email "VPNs" such as WorldSecure which
convert plaintext mail to S/MIME and vice versa, thus CPU load for such
servers becomes significant). Nevertheless, it seems to me that S/MIME is
much better served by leaving compression out, and putting it into MIME.
(Encoding-type: application/gzip perhaps?).
As for Peter's argument about Non-MIME CMS applications I guess I can only
say that if the underlying content that CMS is encapsulating needs
compression, then the underlying content handler should do it. We could
make the same argument for any presentation-layer like service that we can
for compression (e.g. content needs to be 7-bit clean), but this doesn't
mean that all this encoding should be handled by CMS.
Lastly, the comment was made that it will be difficult to get MIME
implementations to switch over to using a compressed type. This has a
grain of truth, but ask youself which is easier: supporting a compression
MIME encoding, or supporting S/MIME? Non-trivial architectural changes
will always take a while to propagate.
This said, I can't see a real problem with supporting a CompressedData type
(apart from the fact that I don't like it), provided it is optional (i.e.
you have to know that the person at the other end supports it to use it).
While not the best solution it possibly has some value for encapsualting
legacy protocols in CMS blobs.
Cheers.
--
Dean Povey, | e-m: povey(_at_)dstc(_dot_)edu(_dot_)au | Cryptozilla:
Research Scientist | ph: +61 7 3864 5120 | www.cryptozilla.org/
Security Unit, DSTC | fax: +61 7 3864 1282 | Oscar - PKI Toolkit:
Brisbane, Australia | www: security.dstc.edu.au/ | oscar.dstc.qut.edu.au/