OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-msg message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: RE: [ebxml-msg] What Next?


I would like to chime in and agree with David.

In addition, I've been working on a SMTP implementation and there are
inherent problems with XMLDSIG and sending 7-bit "Content-encoding"
payloads. I would sign the message and payloads but the payloads CR/LF would
be re-written differently in mail transport or when read from the mail
provider. The way I worked around this was to force text messages to be
base64. I could add a transform for the payloads signing but there is no
guarantee the receiving MSH can handle transforms not in the MS spec. Even
with the base64, there are some (most don't) mail servers that will decode
the base64 and re-encode it for re-transmittion. The only solution if going
through this type of mail hop is to encrypt the entire message with S/MIME.
Javamail does provides the ability to stream the data with different CR/LF
formats(platform and canonical MIME format) but since it not clear what the
signing MSH format used this doesn't really work. You might think the
canonical MIME format would be the choice but some payloads come from disk
in our implementation and we stream them right into the message rather than
parse them which saves on memory and CPU.

I also agree with David on the encapsulation. I think this was the best way
to encrypt everything and still interopt with other MSHs.

Cliff

> -----Original Message-----
> From: David Fischer [mailto:david@drummondgroup.com]
> Sent: Wednesday, April 10, 2002 1: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