RE: Compression Order

David,

I think this compression discussion is constructive.  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.
Signatures might be small but the time it takes to generate them has a
direct corelation to the size of the file.  Two, AS2 is used 99.9999% of the
time in batch mode where there is no user intervention.  How many time can
anyone recall someone opening up a EDI 850 purchase order and reviewing it
and then deciding to sign it.  These systems simply do not work that way.
The typical implementation would send (and sign) everthing in a particular
directory.  AS2 is not similar to PGP mail.  Three, exclusive support of the
"compress then sign" model does not prohibit the user from viewing each
individual file if he/she so wishes and then making the decision to sign the
uncompressed data.  In this rare instance where the user has viewed this
individual file and desires to sign it, he would always be sending the file
after he signs it.  In other words, there would be no case where the user
would sign and then not send to the trading partner.   The decision to sign
is a work process handled in the GUI (or command console).  The user then
passess all the various settings to software module that compresses, signs,
encrypts, computes message digests, encodes, etc.  This software module
receives data passed from the GUI telling it to  sign a individual file or
group of files.  It then compressess the file and then signs it.  Thus,
there is no need in the standard to support signing uncompressed data prior
to compression.  

This particular issue will have a TREMENDOUS impact on performance.  We
should not give our customers the option to sign uncompressed data if they
use compression.  


Regards,


Christian Putnam
iSoft

  

-----Original Message-----
From: David Fischer [mailto:[email protected]] 
Sent: Wednesday, March 06, 2002 10:04 AM
To: Kepa Zubeldia
Cc: [email protected]
Subject: RE: Compression Order



True, but we don't support multiple signatures.

Serial signatures (signing over the previous signature) are fairly simple,
as a construct.  Parallel signatures are undefined at the moment.  We could
easily support serial signatures in AS2.

A compressed signature is not "mush" any more than receiving a .ZIP
attachment would be.  OTOH, receiving an encrypted object without possessing
the private-key is truly "mush" to the recipient/potential signer.  In the
case of serial signatures and compression, the inner part can be read
(decompressed) without disturbing the signature so I don't know why multiple
signatures would be an argument either way?

Regards,

David Fischer
Drummond Group.

-----Original Message-----
From: Kepa Zubeldia [mailto:[email protected]]
Sent: Tuesday, March 05, 2002 9:11 PM
To: David Fischer
Cc: [email protected]
Subject: Re: Compression Order


What if you need more than one signature?  Common situation in healthcare.
It would have to be

sign - sign - sign - compress - encrypt

So you know what you are signing at each step, before it turns into "mush".

Kepa


David Fischer wrote:

> We are beginning to implement the Compression Draft specification:
>
>
>
> http://www.ietf.org/internet-drafts/draft-ietf-ediint-compression-00.t
> xt
>
>
>
> and an implementation decision has arisen.  When Compression is 
> applied in concert with Signatures, which should be applied first?
>
>
>
>     Compress + Sign    or
>
>     Sign + Compress
>
>
>
>         and
>
>
>
>     Compress + Sign + Encrypt   or
>
>     Sign + Compress + Encrypt
>
>
>
> Different companies have presented valid business cases for each 
> alternative.
>
>
>
> The advocates for Signing first desire the signature to be over 
> readable text (you know what you are signing -- which is why we never 
> Sign after Encrypting).
>
>
>
> The advocates for Compressing first desire performance improvements.  
> In this case, Compression is compared as just another encoding scheme 
> so it is really still plain text.
>
>
>
> Discussions thus far have resulted in a consensus that the 
> implementors should be able to apply these functions in either order 
> when sending. When receiving, the implementations should be able to 
> process either case.
>
>
>
> We are looking for further discussions. . .
>
>
>
> Regards,
>
>
>
> David Fischer
>
> Drummond Group.