RE: Some feedback on Packaging v0-6

[Dick Brooks <dick@8760.com>]

Joe, see responses inline.

Dick Brooks
Group 8760
110 12th Street North
Birmingham, AL 35203
dick@8760.com
205-250-8053
Fax: 205-250-8057
http://www.8760.com/

InsideAgent - Empowering e-commerce solutions

> -----Original Message-----
> From: Joe Lapp [mailto:jlapp@webMethods.com]
> Sent: Friday, August 04, 2000 11:27 AM
> To: ebxml-transport@lists.ebxml.org
> Subject: Some feedback on Packaging v0-6
>
>
> List-Unsubscribe:
>  <mailto:ebxml-transport-request@lists.ebxml.org?body=subscribe>
> List-Archive: <http://lists.ebxml.org/archives/ebxml-transport>
> List-Help: <http://lists.ebxml.org/doc/email-manage.html>,
>  <mailto:ebxml-transport-request@lists.ebxml.org?body=lp>
>
> 1)  My understanding is that the plan is to allow multiple application
> payloads to occur as multiple MIME parts, but the Packaging spec seems to
> imply that they must all occur within a single MIME part.  The diagram
> shows one part, the text refers to this one part, and at one
> point the text
> even refers to the packaging of payloads within this part by saying that
> such packaging is application-dependent.  All ebXML messages would use no
> more than two MIME parts.  If this isn't what is intended, we
> might want to
> clarify the spec, since we want even dummies like me to be able
> to read and
> implement the thing, right?
>
The packaging spec defines a single "container" (a.k.a. MIME body part) to
hold a payload, as you've indicated. An implementer can place ANYTHING into
this container, and label it with the correct MIME type. This includes a
multipart/related payload containing several body parts. For example:

Content-type: multipart/related; type="application/vnd.eb+xml";
boundary="XXX"; .........

	--XXX
	Content-type: application/vnd.eb+xml

	ebXML header here......

	--XXX
	Content-type: multipart/related; boundary="OOO"

		--OOO
		I'm the first part of the payload

		--OOO
		I'm the second part of the payload

		--OOO
		I'm the nth part of the payload

		--OOO--
	--XXX--




> 2)  The spec doesnt directly state whether the header MIME part
> must occur
> as the first MIME part.  Although it does appear this way in the
> illustration, its not clear whether the illustration is just intended to
> exemplify an ebXML message.  Since the Content-ID identifies the header,
> strictly speaking, the header need not be first.  However, there may be
> efficiency concerns that would warrant requiring it to be first.
>

Good catch, we're going to make this explicit in the next draft. The ebXML
header must be the first body part.

> 3)  Section 4.5.4 "Optional Support for Signed Headers" says that headers
> may be signed, but does not make any statement about whether they can be
> encrypted.  Section 4.6.4 "Optional Support for Signed and Encrypted
> Payloads" says that payloads may be signed and encrypted.  Presumably
> because encryption was not mentioned in 4.5.4, headers may not be
> encrypted.  However, logically speaking, the spec does not
> preclude headers
> from being encrypted.  Will ebXML allow headers to be encrypted?  My
> understanding is that the answers to these questions will appear in the
> "Messaging Security and Signature Specification."  But it appears to me
> packaging spec is already providing a partial answer and is claiming that
> these answers are within its scope.  Should we clarify this verbage?
> Remove it?  Leave it?
>

IMHO, the details describing what is/is not allowed with regard to security
is the domain of the Security spec. Perhaps we should change the enveloping
spec to refer to the security spec in this regard.

On a practical note, headers can be encrypted, but this may not be
desireable, especially if the information in the header is needed to
identify the correct party/key to use for decryption.

> 4)  Section 4.7 "Message Digest Calculation" defines the portion of an
> ebXML message that is to be used in the digest.  Where does the digest
> itself go?  Seems like that would be a packaging issue, rather than an
> issue for the security spec.  Maybe we should resolve this issue when we
> tackle the security spec, updating the Packaging spec accordingly then.
>

Signed objects should be packaged according to RFC 2015 or RFC 2633, based
on the crypto tool used (PGP or S/MIME).

> - Joe
>