MHonArc v2.5.2 -->
ebxml-msg message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Subject: 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.
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Powered by eList eXpress LLC