[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [ebxml-msg] What Next?
David, I believe that I understand your point; however, I fear we are missing the more important issue--business process. It is my view, and the view of many others, that the MSH is intended to support business processes. There are valid business processes where the security services applied to the payloads must persist beyond the MSH to the application. There are financial and mortgage models where the signatures must persist, and be added to, over time. The confidentiality requirements are just as real--especially with HIPAA on the horizon. I must agree with Arvola that we carefully explore the use of XML-Enc and XML-DSig. I do not believe that encrypting the MIME package provides the persistent security that is demanded by the business processes. Ralph Berwanger -----Original Message----- From: David Fischer [mailto:david@drummondgroup.com] Sent: Wednesday, April 10, 2002 3:54 PM To: Arvola Chan; ian.c.jones@bt.com; ebxml-msg@lists.oasis-open.org Subject: RE: [ebxml-msg] What Next? Yes, we had this same problem with XMLDsig. We can sign/encrypt the data in the payload but we will miss the MIME headers. A better solution is to encrypt the entire message in one shot, thus eliminating these holes. It will also be more efficient. Where we got into trouble was when we pulled the values (AckRequested, SyncReply) out of the Via element and made them top level elements. We could have just excluded the Via element and thus any changes within that element would not have invalidated the signature. Studying the MS document would be a good idea. I just read this document and I didn't see it address either of our concerns, namely the problems caused by actor=next and the issue of signing attachments. Attachments are mentioned in passing (section 3.1) but not actually addressed. I will read it again. David. -----Original Message----- From: Arvola Chan [mailto:arvola@tibco.com] Sent: Wednesday, April 10, 2002 2:37 PM To: David Fischer; ian.c.jones@bt.com; ebxml-msg@lists.oasis-open.org Subject: RE: [ebxml-msg] What Next? David: I am confused. Why are you saying "it won't encrypt the headers"? The introduction to the XML Encryption states: "This document specifies a process for encrypting data and representing the result in XML. The data may be arbitrary data (including an XML document), an XML element, or XML element content. The result of encrypting data is an XML Encryption EncryptedData element which contains (via one of its children's content) or identifies (via a URI reference) the cipher data." Last October, Microsoft published a WS-Security specification that is supposed to make use of XML Digital Signature and XML Encryption. I believe it is also supposed to work with WS-Routing. I think we should study the Microsoft specs before concluding that XML Encryption is not relevant for ebMS. -Arvola -----Original Message----- From: David Fischer [mailto:david@drummondgroup.com] Sent: Wednesday, April 10, 2002 9:30 AM To: Arvola Chan; ian.c.jones@bt.com; ebxml-msg@lists.oasis-open.org Subject: RE: [ebxml-msg] What Next? I have read the XML Encryption spec (last Fall) and it looks like it has the same flaws we found in XMLDsig -- it won't encrypt the headers. This is not a flaw in the XML Encryption spec but a deficiency in extending the spec for use outside XML. These specs were never intended to be used for our situation. When we talked to the XMLDsig committee, they felt we were incorrectly mixing technologies to put XMLDsig and SOAP/MIME together. We are discovering that we have painted ourselves into a corner with XMLDsig (won't work with SOAP multihop). We have a serious situation in XMLDsig v2.0 with intermediaries modifying SOAP elements thus invalidating signatures and security concerns with signatures not covering the entire message. Why wouldn't using XML Encryption be the same mistake? Regards, David. -----Original Message----- From: Arvola Chan [mailto:arvola@tibco.com] Sent: Wednesday, April 10, 2002 10:37 AM To: David Fischer; ian.c.jones@bt.com; ebxml-msg@lists.oasis-open.org Subject: RE: [ebxml-msg] What Next? Now that XML Encryption is a W3C candidate recommendation, we ought to figure out how it is to be used in conjunction with ebMS. We also may want to coordinate with the CPP/A team to determine how intermediaries ought to be configured. -Arvola -----Original Message----- From: David Fischer [mailto:david@drummondgroup.com] Sent: Wednesday, April 10, 2002 8:06 AM To: ian.c.jones@bt.com; ebxml-msg@lists.oasis-open.org Subject: RE: [ebxml-msg] What Next? We need to consider Encapsulation again. This has a number of potential uses: Encryption (encrypt the entire document including MIME headers) Forwarding/Multi-hop (especially with the identified problems with Signatures) Third-Party Processing (Intermediate Timestamps...) Chunking (sending extremely large files in pieces) I am sure there will be others. We used this concept in the UCC Interop test to do encryption and it worked quite well. See document attached. Regards, David Fischer Drummond Group. -----Original Message----- From: ian.c.jones@bt.com [mailto:ian.c.jones@bt.com] Sent: Wednesday, April 10, 2002 9:52 AM To: ebxml-msg@lists.oasis-open.org Subject: [ebxml-msg] What Next? Team, I hope you have all had a pleasant break over the last couple of weeks. As the title says what do we do next? It is up to you, but here are some ideas to start with. 1 - we MUST capture, answer and resolve any question and issues during the 3 month public review of version 2.0 2 - The IIC TC would like to produce a conformance test/suite/documentation for version 2.0, they will obvious need help from us to do this. 3 - The Business interface layer has never been written - do we need it? 4 - A primer/introduction to the messaging service 5 - A document to describe the minimum implementation. This may be linked to the IIC TC point above. Question: - Do we still have outstanding requirements that still need to be addressed? i.e. a definable business need for them. Over to all of you for comments. Ian Jones Chair OASIS ebXML Messaging Services TC Email: ian.c.jones@bt.com ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl> ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl> ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl> ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC