OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-msg message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [ebxml-msg] Coimpression for ebMS 3.0 and CPPA 2.1/3.0 discussion RE: [ebxml-dev] compression and encryption of payloads


Title: Re: [ebxml-msg] Coimpression for ebMS 3.0 and CPPA 2.1/3.0 discussion RE: [ebxml-dev] compression and encryption of payloads

Thanks for that real world update! So to borrow a snippet from that doc, the Packaging element would ref something like

 

<eb:SimplePart eb:id="SP_ID_01_gzip" eb:mimetype="application/gzip">

<eb:NamespaceSupported

eb:location="/STAR/Rev1.2/BODs/Standalone/ProcessPartsOrder.xsd"

eb:version="2.0">

http://www.starstandards.org/STAR

</eb:NamespaceSupported>

</eb:SimplePart>

 

 

A thing that we need to consider for the 3.0 level ebXML specifications is IMO whether we want to supply some compression solution for use within payloads in the SOAP body.

 

But, it might be better-- since we still support SWA-- to use the payload-in-a-body-part approach.

 

I don’t think there is a WS-* specification addressing compression except perhaps XMLP specs that would relate to doing it with XOP and MTOM…

 

The w3c has not yet delivered a binary/compressed XML proposal, at least last time I checked.

 

Dale

 


From: Ric Emery
Sent: Thursday, April 20, 2006 8:43 AM
To: Dale Moberg; Torsten Kirschner; ebxml-dev@lists.ebxml.org; Srinivas; Vishal Sinha
Cc: ebxml-msg@lists.oasis-open.org; ebxml-cppa@lists.oasis-open.org
Subject: Re: [ebxml-msg] Coimpression for ebMS 3.0 and CPPA 2.1/3.0 discussion RE: [ebxml-dev] compression and encryption of payloads

 


If you are interested in how others handled compression as part of ebMS 2.0 you could take a look at what the STAR Group did. Their spec is at http://www.starstandard.org/sigs/infrastructure/default.htm . The STAR Group solution is not part of the ebMS 2.0 standard. But may be helpful to you. The solution has been interop tested between at least 3 ebMS vendors. The interop was completed back in Dec of 2004.

Ric
Cyclone/Axway


On 4/20/06 8:29 AM, "Dale Moberg" <dmoberg@cyclonecommerce.com> wrote:

I am sending these remarks to the CPPA TC that is currently working on an update and maintenance version for CPPA (2.1 and/or 3.0 level)
 
Certainly the Packaging option in CPP/CPA exists now for some ways of specifying compression but it would be done as a matter of bilateral agreement, and not as a described option of ebMS. Full support for the Packaging element would not be difficult to add if it were tied to user interest.
 
So I will also send your discussion to the ebMS TC that is trying to advance to a Committee Specification in the next weeks.
 
 
Dale Moberg
Cyclone/Axway
Office of the CTO, Chief Architect
 
 


From: Torsten Kirschner [mailto:torsten.kirschner@sandbox.no]
Sent: Thursday, April 20, 2006 12:00 AM
To: ebxml-dev@lists.ebxml.org
Cc: 'Srinivas'; 'Vishal Sinha'
Subject: SV: [ebxml-dev] compression and encryption of payloads

Hi,



I agree with Srinivas, but would like to add the following observations.



CMS-based S/MIME lacks an automagic, transparent compression as PGP offers out of the box. As Srinivas points out, doing several operations like signing, compression or encryption on the same cleartext result in nested MIME bodyparts.

By the way, encryption followed by compression is supposedly counter-productive with regard to the latter. Case (1) should therefor be avoided.



* Compression can be done as Srinivas outlines, but there are other alternatives.

Newer CMS and S/MIME versions offer the CompressedData [RFC3274] / Content-Type: application/pkcs7-mime; smime-type=compressed-data [RFC3851].



Other standards, like EDI-INT, RFC3854 and ENV13608-2 also describe ways of doing this.

Unfortunately, ENV13608-2 is not very clear and I have come to the conclusion that the resulting implementations used around here is simply incorrect or at least highly proprietary.

RFC2634 on the other hand is a good example of both how something should be described and illustrated.



* From an ebXML perspective, this issue should be very simple. In version 2.0 of the CPA standard, all of this is addressed in the Packaging section. However, I am not aware of any implementation actually using this element.



Since transmitting messages securely turned out to be a major argument for ebXML, I suggest the ebMS 2.0 appendix C "Supported Security Services" should be ammended with a detailed, standard description of how these are implemented. Especially profile 13, not limited to XML-security, but also using S/MIME, preferably S/MIME v3.1.



I see that the ebMS version 3.0 addresses some of these issues, but merely changing the syntax and its location may not suffice.



I'll see what I can come up with to contribute.



best regards

Torsten


 



Fra: Srinivas [mailto:Srinivas@crimsonlogic.com]
Sendt: 7. april 2006 11:51
Til: Vishal Sinha; ebxml-dev@lists.ebxml.org
Emne: RE: [ebxml-dev] [Announce] simple ebXML Collaboration Protocol Agreement (CPA) OpenOffice Form
Hi,
To my knowledge the payload(s) will be added to the ebXML message by warping with the Mime Object, this object will be then
(1)
    Encrypted and then compressed and added to ebXML payload part Or
(2)
    Compressed and then encrypted and added to ebXML payload part.

Case (1) If the object is first encrypted  the mime header will be */pkcs7-mime and then you will compress the message, when adding the compressed message to ebXML SOAP message this will have the content type as */gzip. So, once you receive any Mime message with this case, then the mime message extraction should do a recursive check, means first extraction will give you the gzip content type, once this is Identified then the extracted object is Mime Object again check the content type again this will give the content type as */pkcs7-mime, once identified then decrypt the message.

Case(2) Similarly first compress the mime message this will generate the content type as */gzip, after compress then create another Mime which will be encrypt the gzip content, this will mime will have the content type as */pkcs7-mime, while extracting the payload you have to first extract the encrypted messages and then extract the gzip message.
 
Hope this won’t confuse you.
 
Regards,
Srinivas.
 
 
 


From: Vishal Sinha [mailto:sinhavis@gmail.com]
Sent: Friday, April 07, 2006 5:14 PM
To: ebxml-dev@lists.ebxml.org
Subject: Re: [ebxml-dev] [Announce] simple ebXML Collaboration Protocol Agreement (CPA) OpenOffice Form


Hi everyone,

I have one question on ebXML. If someone can reply that will be good help.

1) The payloads in ebXML can be encrypted and compressed. When my application receives the ebXML message, it checks  the content-type of that payload, if it is */gzip, it concludes that the payload is compressed and if it is */pkcs7-mime it concludes that the payloads is encrypted using smime.

Now, the question is what content-type to use if the payload is both encrypted and compressed ?



[...]

 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]