RE: Security Meeting in Boston; Conceptual Layering

["Burdett, David" <david.burdett@commerceone.com>]

Scott

I agree with your layering and I think it makes sense.

David
PS Now all we need is three letter acronyms for them and we can all be happy
;)


-----Original Message-----
From: Scott Hinkelman [mailto:srh@us.ibm.com]
Sent: Monday, December 11, 2000 8:39 AM
To: Burdett, David
Cc: 'andrew.eisenberg@progress.com'; Ebxml-Transport (E-mail);
ebxml-tp@lists.ebxml.org; ebxml-bp@lists.ebxml.org
Subject: RE: Security Meeting in Boston; Conceptual Layering


David, I agree that the app should just provide the data, and that is
indeed our current design point for
our (IBM) POC API.

As I am sure you agree, again since ebXML has no API, Andrew's question can
only be answered conceptually,
and leads to the difficulty in this type of conversation. In this case the
specifics are around issues of which
layer(s) does MIME packaging, and who knows the MIME boundary when. So,
last week in Boston between
TP and BP, like other times, we roughly discussed the following conceptual
layers:

Application (perhaps an existing non-collaborating application)
Application Collaboration Adapter (makes an existing non-collaborating app
collaboration)
Middleware (supports behavior needed to for BP Signals, etc)
MSH (packaging, etc)
Transport (http, etc)

Andrew -Unless there is agreement on at least conceptual layering at
responsibilities, the question can not be conceptually
answered since ebXML is not on a path for API specification, only wire
format.

Scott Hinkelman, Senior Software Engineer
XML Industry Enablement
IBM e-business Standards Strategy
512-823-8097 (TL 793-8097) (Cell: 512-940-0519)
srh@us.ibm.com, Fax: 512-838-1074



"Burdett, David" <david.burdett@commerceone.com> on 12/08/2000 04:40:01 PM

To:   "'andrew.eisenberg@progress.com'" <andrew.eisenberg@progress.com>,
      "Ebxml-Transport (E-mail)" <ebxml-transport@lists.ebxml.org>
cc:
Subject:  RE: Security Meeting in Boston




I  don't think so. What the application needs to do is provide the MSH
with

   the  data needs to be transported
   the  destination and any other information that needs to go in the
   header


The  MSH can then construct the complete message.

David
-----Original Message-----
From: Andrew Eisenberg  [mailto:aeisenbe@progress.com]
Sent: Friday, December 08, 2000 7:49  AM
To: Ebxml-Transport (E-mail)
Subject: RE: Security  Meeting in Boston



I'm not sure that I see how the  pieces are fitting together here.


3.        Applications  should provide confidentiality using S/MIME or
PGP/MIME.  The POC will be asked to ensure that  encrypted payloads can be
reliably communicated between MSH  agents.


The manifest is part of the  message header and points to the payload
document or documents. Does this  mean that the application has to
construct the manifest as  well?

                         -- Andrew

----------------------------------------------------------------------------
----
Andrew  Eisenberg
andrew.eisenberg@progress.com
Progress Software Corp.
14 Oak  Park                                         phone: 781-280-4526
Bedford, MA   01730                                  fax:   781-280-4949

-----Original  Message-----
From: Ralph Berwanger  [mailto:rberwanger@bTrade.com]
Sent: Thursday, December 07, 2000  4:33 PM
To: Ebxml-Transport (E-mail)
Subject: Security  Meeting in Boston



So  far we have had a very lively discussion regarding satisfaction of the
security requirements for the Message Servicing Specification.  Based on
the discussions the  following items were agreed.



1.        Payload  security is not the responsibility of the MSH.  The
function may be performed on a  B2B server that also hosts the MSH; however
the MSH does not own the  operations.  There was agreement  that the MSH
would not alter the  payload.

2.        Applications  should be able to sign payloads using S/MIME,
PGP/MIME, or XML-DSig.  The POC will be asked to ensure that  signed
payloads can be reliably communicated between MSH  agents.

3.        Applications  should provide confidentiality using S/MIME or
PGP/MIME.  The POC will be asked to ensure that  encrypted payloads can be
reliably communicated between MSH  agents.

4.        The  MSH must support the signing of an entire ebXML document.
There are two alternatives on the  table?one using XML/DSig another using
S/MIME.  These two proposals impact the  current version of the MSH
specification (0.8).  The XML/DSig solution will allow us  to use the ebXML
header, as it is currently defined.  The S/MIME signing does inject
difficulties, especially where they involve multiple signatures or message
routing.

5.        The  MSH must support selective encryption of data within the
ebXML header.  It was agreed that this requirement  could not be satisfied
in phase 1,2, or 3.   It was suggested that S/MIME be used  to satisfy this
requirement?that will require significant restructuring of  the ebXML
Header.  It was also  suggested that we wait and employ XML-encryption once
that standard becomes  available.  Assuming that the  XML-encryption work
takes a form similar to the XML/DSig product, we should  be able to use the
XML-encryption standard with the current structure of the  ebXML header.



Chris  and Maryann are pleading for a teleconference to discuss points 4
and 5. The  major question is whether the group is prepared to restructure
the ebXML  document header to support the broad security requirement (as
they apply to  the entire ebXML document).  It  is important that TRP think
about the proposals that are going to come from  the security group and
that they are prepared to discuss them during the  face-to-face scheduled
for January (London).   Formal notification of this  request will be coming
directly from Maryann, the chairperson of the  Security Work Group.