Terry
Of course, this assumes the use of lossless compression, and zlib as
proposed by Peter as the mandatory-to-implement algorithm in the
compression proposal satisfies that.
However in the future, and for some applications, one might wonder if a
lossy compressor might be favoured (e.g. JPEG if you are signing images
emitted by a surveillance camera).
In this case of course, it must be: compress then sign
Tony Capel,
Comgate Engineering Ltd.
-----Original Message-----
From: owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org]On Behalf Of Housley,
Russ
Sent: February 26, 2002 11:21 AM
To: Terry Harding
Cc: ietf-smime(_at_)imc(_dot_)org
Subject: Re: Order of signing and compression operations.
Terry:
A general rule of thumb: sign before compress.
Another general rule of thumb: sign before encrypt.
There are exceptions to both rules. However, the idea is to
sign what you
say, not what you transmit. In the compression context, the
exception may
arise when the content is huge and there is a large difference
between the
following:
Hash( Compress( content ) )
Compress( Hash( content ) )
In this situation, you ought to consider application context and
the reason
for the signature. For example, if an arbitrator is going to
resolve any
dispute, and that arbitrator understands the compression and signature
technologies, then either order is okay.
Russ
At 03:25 PM 2/25/2002 -0700, Terry Harding wrote:
All,
Does the S/MIME group have a preference on the order of operations when
signing and compressing a S/MIME
message when using the compressed data content type for cms.
Should compression occur before signing or should signing occur before
compression or maybe it does not matter.
Any guidance by the S/MIME group would be greatly appreciated.
Terry Harding
Cyclone Commerce