Compression, encryption and authentication - the way ahead?

[David Burdett <david.burdett@commerceone.com>]

This thread on compression (and encryption and authentication) has been an
exceedingly long and tortuous. So, in an attempt to draw it to a close, I
suggest the following:

1. The Transport Group does not address compression in any general sense
whilst not precluding its use in specific instances
2. Our specification should permit discrete parts of messages to be
compressed using established encryption technology (see note belown on
Message Manifest) 
3. We similarly do not specifically address encryption but allow the use of
existing encryption technologies
4. We do address authentication and security. For eCommerce, it will be
essential in many instances that the authenticity of a message can be
establised. Specifically the recipient of a message will not know whether to
act on or trust the message unless the authenticity of the sender is known.

Anyone disagree with this approach?

David

Note on Message Manifest
========================
In an earlier email I suggested that Message Manifest could look something
like:

 <MessageManifest>
   <DocumentReference Id='AB273' DocumentType='Text/XML'
      URI='urn:example.com:ACV-CN-1999/2456#MessageRoutingInfo'
      Purpose='MessageRoutingInfo' >
   <DocumentReference Id='AB274' DocumentType='Text/XML'
      URI='urn:example.com:ACV-CN-1999/2456#Invoice'
      Purpose='NewInvoice' >
   <DocumentReference Id='AB275' DocumentType='Image/Jpg'
      URI='urn:example.com:ACV-CN-1999/2456#InvoiceImage'
      Purpose='InvoiceAttachment' >
 </MessageManifest>

The purpose of a Message Manifest is to identify the other "documents"
(apart from the Message Header itself) that are associated with the message
by including a Document Reference for each. The other documents will either
be in the same message or somewhere out on the web.

So I propose that, if someone wants to support compression or encryption,
then all they need to do is specify an appropriate DocumentType in the
Manifest to identify it as such and then make sure that the document is
properly encoded

Another encryption alternative, if MIME is being used as the outer wrapper
for the message, is to use S/MIME to provide any necessary encryption.

-----Original Message-----
From: Matthew MacKenzie [mailto:matt@xmlglobal.com]
Sent: Saturday, March 11, 2000 3:00 PM
To: Solinsky, Jason
Cc: 'David RR Webber'; David Burdett; Ebxml; 'Dick Brooks'; ebXML
Architecture (E-mail)
Subject: RE: Compression (was RE: COMPLEXITY BIG ISSUE)



> nature need to be performed at a lower level than compression. I therefore
> ask why security is our concern but not compression (which can
significantly
> improve security by removing redundancy prior to encryption).

I think everyone is just trying to dismiss this thread for a little while.
it is quite possible that, when decisions on security are made, the
compression issue will come up, and a methodology for
compression+encryption can be thought up at that time.  Maybe we will end
up with ZLib+SSL, or BZIP+PKI, who knows...but it won't be rocket science.
I think the key thing is that the Transport group decide on some sort of
enveloping standard, which would allow participant level decisions for
compression and encryption, maybe the format will be a simple routing
message in XML format, stating to and from + a hint as to the comp./encr.
format contained in the message body. 

--
Matthew MacKenzie