From: "Pawling, John" <jsp(_at_)jgvandyke(_dot_)com>
All,
Compression is not a security service, so it should not be included in the
S/MIME specs. Developing an Internet standard for compressing data is an
issue that is related to Internet data communications, in general, not just
S/MIME. There may be folks who are not participating in the S/MIME WG that
would greatly benefit from an Internet compression standard. In summary, I
believe that this discussion should take place in a more general data
communications group, not the S/MIME WG.
Unfortunately, as Peter pointed out, the discussion hasn't happened,
and isn't likely to happen, at the MIME level. And if a compressed
MIME-type did exist, it would not cover non-S/MIME applications of
CMS. Perhaps CMS itself should be owned by a "more general data
communications group" such as WTS or CAT, but it isn't. As long as
CMS is S/MIME-related, compression within CMS is S/MIME-related.
The philosophy adopted by other Security Area WGs is that if security
breaks something, security should ameliorate the damage to the extent
possible. Thus PPP includes compression because PPP encryption breaks
modem compression. IPsec includes it because IPsec breaks PPP
compression. TLS includes it because TLS breaks IPsec compression. As
long as CMS will be used with compressible data and with
compression-enabled lower layers (a network stack, or disk-doubler),
CMS should address the problem it causes.