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 ?
[...]