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
Comgate Engineering Ltd.
[mailto:owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org]On Behalf Of Housley,
Sent: February 26, 2002 11:21 AM
To: Terry Harding
Subject: Re: Order of signing and compression operations.
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
arise when the content is huge and there is a large difference
Hash( Compress( content ) )
Compress( Hash( content ) )
In this situation, you ought to consider application context and
for the signature. For example, if an arbitrator is going to
dispute, and that arbitrator understands the compression and signature
technologies, then either order is okay.
At 03:25 PM 2/25/2002 -0700, Terry Harding wrote:
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.