RE: the mime issue in the ms draft

[Igor Balabine <igorb@netfish.com>]

Dick,

Please see my comments inline marked [IB]...


At 08:13 AM 9/6/00 -0500, Dick Brooks wrote:
>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.

[IB] I think Marc Bressinger provided an absolutely correct answer to your
question. There is no reason for splitting an atomic data uint (such as a
*transport independent* ebXML message) between the application and the
transport layers.    


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

[IB] What particular features of S/MIME v.3 do you plan to use for ebXML
messaging? I think it's wiser to stick to the lowest common denominator and
use v.2 for the time being while cryptography providers bring robust CMS
(aka S/MIME v.3) compliant libraries to the market. Again, why a widely
deployed and well known S/MIME v.2 is not enough? 

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

[IB] Dick, I participated in a similar discussion as well (in a different
forum ;-) As it is stated in my original message I just wanted to attract
attention to certain not so obvious implications of the proposed solution
when an intermediary(ies) is involved. The proposed solution works
absolutely fine (it is unambigous) in the point-to-point case. The problem
arises when a message is routed through an intermediary and the
non-repudiation property of the route is requested.

Thanks.

-Igor   

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