RE: [ebxml-msg] What Next?

[Dick Brooks <dick@systrends.com>]

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

Cliff, my responses are inline:

 

>3 reasons.

 

>1. This doesn't encode the SOAP Envelope. If you

> want to obscure this information (the manifest

> information, etc) you need to encrypt the entire

> message.

 

Actually, all HTTP headers and data, which includes the entire ebXML message, are encrypted within an SSL/TLS session.

 

>2. What about SMTP?

 

Appendix B of the ebMS spec addresses this, ref:

An ebXML Message Service Handler MAY use transport layer encryption to protect the confidentiality of ebXML messages.  The IETF "SMTP Service Extension for Secure SMTP over TLS" specification [RFC2487] provides the specific technical details and list of allowable options, which may be used.

 

Note: RFC2487 has been replaced by RFC3207, ftp://ftp.isi.edu/in-notes/rfc3207.txt

 

 

>3. What about multihop? Maybe you don't want 

>the information available at the intermediate hop.

 

It would seem to me that an intermediary needs access to the ebXML header information in order to perform it's role as an intermediary. Clearly one may not want an intermediary to have access to the business data contained in the payload container and that should be encrypted using PGP or S/MIME or something else.

 

 

Dick Brooks
Systrends, Inc
7855 South River Parkway, Suite 111
Tempe, Arizona 85284
Web: www.systrends.com <http://www.systrends.com>
Phone:480.756.6777,Mobile:205-790-1542,eFax:240-352-0714
 

-----Original Message-----
From: Cliff Collins [mailto:collinsc@sybase.com]
Sent: Thursday, April 11, 2002 12:47 PM
To: Brooks, Dick; David Fischer; ian.c.jones@bt.com; ebxml-msg@lists.oasis-open.org
Subject: RE: [ebxml-msg] What Next?

3 reasons.

 

1. This doesn't encode the SOAP Envelope. If you want to obscure this information (the manifest information, etc) you need to encrypt the entire message.

2. What about SMTP?

3. What about multihop? Maybe you don't want the information available at the intermediate hop.

 

Cliff

-----Original Message-----
From: Dick Brooks [mailto:dick@systrends.com]
Sent: Thursday, April 11, 2002 10:28 AM
To: David Fischer; ian.c.jones@bt.com; ebxml-msg@lists.oasis-open.org
Subject: RE: [ebxml-msg] What Next?

David,

 

I'm unclear why encapsulation is necessary to encrypt entire messages, especially if a payload item is already encrypted. It seems SSL would provide sufficient encryption of an entire message, including MIME headers.

 

I could see using S/MIME of OpenPGP to digitally sign an entire message, but SSL should be sufficient for encryption purposes.

 

Am I missing something?

Dick Brooks
Systrends, Inc
7855 South River Parkway, Suite 111
Tempe, Arizona 85284
Web: www.systrends.com <http://www.systrends.com>
Phone:480.756.6777,Mobile:205-790-1542,eFax:240-352-0714
 

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