RE: [ebxml-msg] What Next?

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

Sorry 
for the confusion but it was really 2 points where the first item was 
informational about what would be exposed in the other 
points.

 

See 
comments below in "blue".

  

  
 

  

  
>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

  
 

  

  
TLS 
  is not really a good option IMO. To give you an example why from the security 
  section of the RFC:

  
 

  
<!--StartFragment-->7. Security 
  Considerations

   It should be noted that SMTP is not an 
  end-to-end mechanism. Thus, if
   an SMTP client/server pair 
  decide to add TLS privacy, they are not
   securing the transport 
  from the originating mail user agent to the
   recipient.  
  Further, because delivery of a single piece of mail may
   go 
  between more than two SMTP servers, adding TLS privacy to one 
  pair
   of servers does not mean that the entire SMTP chain has 
  been made
   private. Further, just because an SMTP server can 
  authenticate an
   SMTP client, it does not mean that the mail 
  from the SMTP client was
   authenticated by the SMTP client when 
  the client received it.

  
Most 
  implementers will want to use the existing mail system at their site and will 
  not be able to convince IT to make all servers between partners to be TLS. 
  There are also some man-in-the-middle attack" problems with TLS that require 
  special consideration outside of the MSH layer.

  
 
 

  
>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.

  
  
  
Encapsulating the message still allows the hop all access to an 
  "ebxml header" but not the "real" message header with the manifest of the real 
  payloads. The hop should be able to route on the header and add signatures or 
  whatever.

  
 

  
Cliff