Re: Manifest Element - Where located? - 2

[christopher ferris <chris.ferris@east.sun.com>]

Bob,

Please see below.

Cheers,

Chris

"Miller, Robert (GXS)" wrote:
> 
> David,
> 
> The need to sign/encrypt messages extends beyond ebXML.  I expect that a
> (non-ebXML) security service will be defined that uses the SOAP-ENV:Header
> to feed the security processes (such work is already well underway).

Actually, for signing, the ebXML Message Service specification addresses
this already. There aren't likely to be many if any changes as a result of
the adoption of SOAP. The Reference elements determine what is signed. The
specification is quite clear (I hope;-) as to how the message is to be signed
using XMLDSig. The xmldsig:Signature goes in the SOAP-ENV:Header element as a 
direct descenant. The xmldsig:Reference elements are supposed to reflect the
same URIs as the eb:Reference elements in the ebXML Manifest. The intent is 
that message signing using XMLDSig happens AFTER the message is assembled
not before.

Encryption, OTOH is a different story until such time as the W3C XML Encryption
WG publishes a spec that achieves RECOMMENDATION status. In this case, S/MIME
encryption is the only viable alternative for *persistent* confidentiality.

> Through layered architecture, the SOAP-ENV:Body (actually, any part of the
> message the security service was instructed to process) would be handled by
> the security process layer.  In the absence of such a package, or in cases
> where security needs to be handled prior to submission for transport, the
> payload would likely not be conformant XML, and so would not be a candidate
> for placement in the SOAP-ENV:Body.  In any event, ebXML might not be in a
> position to control how the application of security affected packaging; it
> might only be in a position to request security services be applied.

At this point, for purposes of providing persistent confidentiality
(encryption of payload) only the application can request this and the
packaging must (of necessity) be MIME based. e.g. the payload "object"
is an S/MIME multipart/encrypted MIME BodyPart.

> 
> And by the way, how do you propose to control the packaging of the business
> payload in MIME?

The TP team is drafting a proposal for defining the packaging of messages
that can be expressed in a CPP/CPA.

The Message Services specification can't and shouldn't really say more
than what we currently do say, that the business or application payload
goes in *separate* MIME body parts from the SOAP envelope MIME body part.
How the individual parts of the application/business payload/content are
packaged is completely outside the scope of TR&P, IMHO.

> 
> Prior to choosing to use SOAP, an answer may have been that the ebXML
> processor would perform the encapsulation, or would pass the content on to a
> lower level package that would do the encapsulating.  With SOAP sitting in
> the middle, MIME encapsulation is not as nearby as it once was.

I actually disagree with this assertion. The actual packaging has always
been one of those processes that was delegated to the infamous "application
services" layer (something between the actual application and the MSH itself).

> 
> I suggest it might be helpful to model the interactions between the
> component services which will comprise the new transport design.  We may
> find we have less control over what happens below the ebXML layer than we
> have been presuming we have.

Indeed, it would be useful, and this has been discussed ad nauseum
in many TCs and F2Fs, but the resources and volunteers to do this
work have been either scarce or non-existant. At this point in the
process, we cannot afford to add more work than we already have on
our plate. I would suggest that this be one of the first orders of
business for whatever body assumes stewardship of the specification(s)
after Vienna.

> 
> Cheers,
>          Bob
> 
> -----Original Message-----
> From: Burdett, David [mailto:david.burdett@commerceone.com]
> Sent: Tuesday, February 27, 2001 4:20 PM
> To: 'Miller, Robert (GXS)'; ebXML Transport Mailing List
> Subject: RE: Manifest Element - Where located? - 2
> 
> Bob
> 
> You said ... "Put the ebXML conformant XML message in the SOAP-ENV:Body."
> 
> The difficulty of doing this is what caused the TRP group to not do SOAP
> last spring. Specifically, you can't put a **complete** XML document inside
> a SOAP body as you have to  remove the prolog. This causes problems if the
> XML document had been previously signed e.g. using XML DSig and including
> the prolog. With your suggestion you have to remove the prolog and therefore
> break the signature.
> 
> The real issue is whether data ebXML will allow additional data to be put in
> the body.
> 
> The general consensus seems to be that we do not which means we should flag
> an error if any data is there. I concur.
> 
> David
> 
> -----Original Message-----
> From: Miller, Robert (GXS) [mailto:Robert.Miller@gxs.ge.com]
> Sent: Tuesday, February 27, 2001 7:44 AM
> To: ebXML Transport Mailing List
> Subject: RE: Manifest Element - Where located? - 2
> 
> Good people,
> 
> Rik says keep it simple.  I agree.  I say simple is this:
> 
> 1) Put ALL of the ebXML header stuff in the SOAP-ENV:Header (where it
> belongs).
>         Some here, some there is NOT simple
> 
> 2) Put the ebXML conformant XML message in the SOAP-ENV:Body.  If no such
> body is present for the message, the SOAP-ENV-Body is empty (or perhaps
> someday, not present.
>         ebXML messages are always in the same place.
> 
> 3) If there are attachments, the attachments are not ebXML messages, they
> are just attachments.
> 
> Cheers,
>         Bob
> 
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: ebxml-transport-request@lists.ebxml.org
> 
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: ebxml-transport-request@lists.ebxml.org
begin:vcard 
n:Ferris;Christopher 
tel;work:781-442-3063
x-mozilla-html:FALSE
org:Sun Microsystems, Inc;XML Technology Development
adr:;;One Network Drive;Burlington;Ma;01824-0903;USA
version:2.1
email;internet:chris.ferris@east.Sun.COM
title:Sr. Staff Engineer
x-mozilla-cpt:;0
fn:Christopher Ferris
end:vcard