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


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-transport message

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

Subject: RE: Some feedback on Packaging v0-6

Joe, see responses inline.

Dick Brooks
Group 8760
110 12th Street North
Birmingham, AL 35203
Fax: 205-250-8057

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"; .........

	Content-type: application/vnd.eb+xml

	ebXML header here......

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

		I'm the first part of the payload

		I'm the second part of the payload

		I'm the nth part of the payload


> 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

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

Search: Match: Sort by:
Words: | Help

Powered by eList eXpress LLC