Title: RE: [ebxml-msg] What Next?
I think minimally next version of ebXML should require
that XML based documents and contents should be encrypted
with XML Encrytion.
The question of what encryption mechanism(s) should
be required for non-XML based content needs to be
decided. SMIME and XML Encryption both possibly could
be options for non-XML content transported as part of
ebXML payload attachments.
The question of interoperability between ebXML v. 2.0
that may support SMIME payload encryption and post-2.0
ebXML that supports (only) XML encryption will be
problematic.
I don't think encrypting whole ebXML messages is a
practical option.
Zahid Ahmed
-----Original Message-----
From: Arvola Chan [mailto:]
Sent: Wednesday, April 10, 2002 3:08 PM
To: David Fischer; ;
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:]
Sent: Wednesday, April 10, 2002 2:40 PM
To: David Fischer; Arvola Chan; ;
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:]
Sent: Wednesday, April 10, 2002 3: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>
----------------------------------------------------------------
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>
