RE: Compression Order

"David Fischer" <[email protected]> Fri, 8 Mar 2002 11:36:53 -0600
Newsgroups gmane.ietf.ediint
Message-ID <[email protected]>
I am sensing a distinct difference of opinion concern which should come first,
signing or compression.  I am also sensing somewhat of a consensus (not
unanimous) that we could allow vendors to choose which order to apply signing
and compression.  This would require implementations to be able to unpackage in
either order (which should not have a significant impact on code since
unpackaging is done by reading the Content-Type).

Is this essentially the feeling of the group?

Regards,

David Fischer
Drummond Group.

-----Original Message-----
From: [email protected]
[mailto:[email protected]]On Behalf Of Carl Hage
Sent: Wednesday, March 06, 2002 12:53 PM
To: [email protected]
Subject: RE: Compression Order



From:           	Christian Putnam <[email protected]>
> However, I believe it would be utterly foolish to support anything other
> than "compress first and then sign" for the AS2 standard.  Why? First,
> the obvious performance gain.

I respectfully disagree. I believe compression should be part of the
encoding and transport process-- added independently of the
signatures used for non-repudiation. This allows the data to be stored
in different forms while retaining the signature with data. It might be
stored compressed, uncompressed, or re-compressed in a different
format (zip/jar). Signing compressed data prevents people from passing
around the signatures in back-end applications.

If you sign before compression, you can compress, transmit, copy,
etc. the data in various formats and places and always retain the ability
to authenticate a signature. Compressing first, mean you cannot
maintain other representations and the single compressed form must
be maintained.

It also makes sense to me people (or a machine) should sign original
plain-text data, not data after encoding, compressing, etc.

The performance difference is negligible in comparison to compression.
The compression algorithms thenselves compute a checksum as well
as compressing the data. Computing an MD5 or SHA hash over
uncompressed data is fast and insignificant in comparison to the time
for compression, encryption, RSA operations, etc.

--------------------------------------------------------------------------
Carl Hage                                              C. Hage Associates
<mailto:[email protected]> Voice/Fax: 1-408-244-8410      1180 Reed Ave #51
<http://www.chage.com/chage/>                          Sunnyvale, CA 94086