Title: RE: [ebxml-msg] What Next?
Element level encryption could be supported using XML
Encryption for both header and body parts. However, we
need to be careful in requiring what parts of header
may be encrypted. This may also imply CPPA/CPP changes
in the future.
We also need to consider adding SAML based authentication
of MSH's and ebXML message originating parties.
W.r.t. MS/GXA ws-security, an area where ebXML alongwith
W3C web services arch group could merge efforts is in
using standard security headers for SOAP-based ebXML
messages. Right now we have an incomplete and not very
standarized set of security extensions for SOAP messages.
thanks,
Zahid
-----Original Message-----
From: David Fischer [mailto:]
Sent: Wednesday, April 10, 2002 1:54 PM
To: Arvola Chan; ;
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:]
Sent: Wednesday, April 10, 2002 2:37 PM
To: David Fischer; ;
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:]
Sent: Wednesday, April 10, 2002 9:30 AM
To: Arvola Chan; ;
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:]
Sent: Wednesday, April 10, 2002 10:37 AM
To: David Fischer; ;
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:]
Sent: Wednesday, April 10, 2002 8:06 AM
To: ;
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: [mailto:]
Sent: Wednesday, April 10, 2002 9:52 AM
To:
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:
----------------------------------------------------------------
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>
