RE: the mime issue in the ms draft

[Dick Brooks <dick@8760.com>]

Igor, see comments inline.

> Besides breaking transport independent packaging (e.g. http vs. ftp) this

I don't understand what you mean by "breaking" transport independent
packaging.
I have personally tested the transport of ebXML messages over HTTP, SMTP and
FTP without
any difficulty or abnormal termination.

> approach makes achiving the non-repudiation property of the message sent
> through an intermediary problematic. According to RFC 2311 (aka
> S/MIME v.2)
> MIME headers of the message being signed are part of the multipart/signed
> message (see Section 3.1).

It's difficult to state if there is a problem with signed ebXML messages
because the TR&P security spec hasn't been written yet. The security spec
may permit an entire ebXML message to be signed and wrapped in a
multipart/signed envelope which  would become the transport level envelope
within an HTTP POST. This means the entire ebXML message is kept intact as
the first body part of the multipart/signed. I'm not trying to steal the
security teams thunder nor bias their solution, I'm simply pointing out that
it's premature to find problems with a spec that doesn't exist yet.

Also, as a side note, I believe ebXML should support S/MIME v3 (RFC
2630-2633) not S/MIME v2.

> This means that an intermediary which was asked
> to provide a proof of routing has to extract the headers of the original
> message from the transport layer handlers. There is no guarantee that the
> EOL characters (and possibly the escaped symbols) are fetched to
> the signer
> EXACTLY as they were received from the wire (e.g. LF on unix systems vs.
> CRLF on Windows based systems, %20 vs " ", etc.). This makes the
> non-repudiation property of the ebXML message implementation dependent.
> Also, firewall proxy filters (such as virus scanners) may amend or replace
> altogether the transport headers. The above circumstances make achieving
> non-repudiation of the business messages problematic.

Again, I think we need to let the security team investigate solutions for
digital signatures/encryption and if there is a problem, have them present
the problems along with proposed solutions. Anything we discuss at this
point is purely conjecture.

FYI, there has been a great deal of discussion about this issue already, I
suggest you search the archives for past discussions and read through the
section regarding message digest calculations within the message service
spec.


Dick Brooks
Group 8760
110 12th Street North
Birmingham, AL 35203
dick@8760.com
205-250-8053
Fax: 205-250-8057
http://www.8760.com/

InsideAgent - Empowering e-commerce solutions