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