You are correct. I assumed lossless compression.
At 01:57 PM 2/26/2002 -0500, Tony Capel wrote:
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.
> -----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,
> 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.
> 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
> 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.
> 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.
> >Terry Harding
> >Cyclone Commerce