[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: Compression, encryption and authentication - the way ahead?
this thread's subject needs to wait until the message structure and headers are addressed. at that time we can discuss in detail authentification, encryption and compression... best regards, rik -----Original Message----- From: firstname.lastname@example.org [mailto:email@example.com]On Behalf Of David Burdett Sent: Sunday, March 12, 2000 12:19 AM To: ebXML Transport (E-mail); ebXML Architecture (E-mail) Subject: Compression, encryption and authentication - the way ahead? 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:firstname.lastname@example.org] 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
Powered by eList eXpress LLC