[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [ebxml-msg] What Next?
Ralph, You are right. If there are needs for the application to have persistent encryption, then the application needs to pass an encrypted payload to the MSH. If the need is for confidentiality at the MSH level, then we need something along the lines of encapsulation. If BPSS decides to use XML documents at the application level then XML-Encryption may be an ideal solution for application level encryption. Regards, David. -----Original Message----- From: Ralph Berwanger [mailto:rberwanger@bTrade.com] Sent: Thursday, April 11, 2002 9:28 AM To: ebxml-msg@lists.oasis-open.org Subject: RE: [ebxml-msg] What Next? It makes no sense to reply to my message, but I need to add one point. Early in the message service discussions, we made certain assumptions about processes. Chris Ferris and I made the argument that we believed that signing and encryption of the business documents would be performed by the applications and that the payload would be handed to the MSH for transport. If we hold that position we could accept David's proposal. In that case, I would like to add some text to the specification qualifying the purpose of any security service provided by the MSH. This could help isolate business issues from technology issues. Ralph Berwanger -----Original Message----- From: Ralph Berwanger Sent: Thursday, April 11, 2002 8:39 AM To: ebxml-msg@lists.oasis-open.org Subject: RE: [ebxml-msg] What Next? I repeat again, the business community does not want to hear that, "encrypting pieces is much slower than encrypting one big chunk...". This argument simply says that technology (read this ebXML) cannot support their business needs. I am just reminding you that there are regulatory issues that compel business to behave in ways that may not make sense to technologist. I am agreeing that the technical solution proposed may be good but it does not mean that the business community can use it. Ralph Berwanger -----Original Message----- From: David Fischer [mailto:david@drummondgroup.com] Sent: Wednesday, April 10, 2002 6:00 PM To: Arvola Chan; ian.c.jones@bt.com; ebxml-msg@lists.oasis-open.org Subject: RE: [ebxml-msg] What Next? We have found that encrypting pieces is much slower than encrypting one big chunk -- one vendor reported a significant decrease in performance compared with single-pass encryption (also true for signing in pieces). Using Encapsulation (encrypting then encapsulating) would also allow some attachment(s) to remain un-encrypted if this is needed. I don't know why anyone would do this but it certainly could be done. There just doesn't seem to be any way that encoding attachments and encrypting them one at a time could possibly be faster than single-pass encryption. We would also have to face the need, during decryption, to decode and put attachments back in the MIME bodyparts. In the mean time, what would be in those bodyparts? Would we just delete those MIME headers and assume the receiving side would reconstruct them? Or, perhaps we would somehow encrypt the MIME headers too? We faced this same problem with XMLDsig & MIME headers and it turned out not to have an easily solution. Encapsulating the S/MIME encrypted part is easy and smooth. What is the business case for fine-grained control of encryption? Regards, David. -----Original Message----- From: Arvola Chan [mailto:arvola@tibco.com] Sent: Wednesday, April 10, 2002 5:08 PM To: David Fischer; ian.c.jones@bt.com; ebxml-msg@lists.oasis-open.org Subject: RE: [ebxml-msg] What Next? One advantage of using XML Encryption is that it gives you fine grained control over what gets encrypted. If the use of S/MIME encryption implies that an entire ebXML message must first be encapsulated before being encrypted, we may be introducing unnecessary encrypting and decrypting overheads. -Arvola -----Original Message----- From: David Fischer [mailto:david@drummondgroup.com] Sent: Wednesday, April 10, 2002 2:40 PM To: David Fischer; Arvola Chan; ian.c.jones@bt.com; ebxml-msg@lists.oasis-open.org Subject: RE: [ebxml-msg] What Next? To continue from the earlier message ... The Microsoft WS-Security document specifically says NOT to use the Enveloped Signature Transform... :-) We had several discussions concerning inclusive vs. exclusive transforms in our signature, and the WS-Security document seems to be saying we picked the wrong path. We decided to go with exclusive because we did not know what extension elements, other than MessageHeader, would be in use. If we had used the inclusive approach (sign this, and this, and this) rather than exclusive (sign everything but this), we would not have the problems we now face with LWS between elements. However, as I recall, we couldn't figure out how to use the inclusive approach and still sign everything -- especially since we anticipate that more extension elements might be used in the future. On WS-Security use of XML Encryption, we could get confidentiality of some headers by enclosing them in the enc:EncryptedData elements. I suppose we could encode attachments and put them in the SOAP:Body so they could be encrypted, but I thought we had agreed not to do this kind of Encoding. This seems to be the method recommended by WS-Security and by XML Encryption. When we decided on using MIME attachments, we set our course toward S/MIME rather than XML Encryption. I suppose we could use XML Encryption on the SOAP headers and use S/MIME for the attachments, but I don't see what this adds over encrypting the entire message. It seems unrealistic to ask implementors to implement two security models in the same implementation. Donald Eastlake, the XML Encryption Editor and the XMLDsig Chair, was the individual we talked to -- who told us we were mixing technologies. Regards, David. -----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> ---------------------------------------------------------------- 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> ---------------------------------------------------------------- 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