Subject: RE: Security Meeting in Boston; Conceptual Layering
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:firstname.lastname@example.org] Sent: Monday, December 11, 2000 8:39 AM To: Burdett, David Cc: 'email@example.com'; Ebxml-Transport (E-mail); firstname.lastname@example.org; email@example.com 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) firstname.lastname@example.org, Fax: 512-838-1074 "Burdett, David" <email@example.com> on 12/08/2000 04:40:01 PM To: "'firstname.lastname@example.org'" <email@example.com>, "Ebxml-Transport (E-mail)" <firstname.lastname@example.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:email@example.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 firstname.lastname@example.org 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.
eList eXpress LLC