OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-transport message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: Re: the mime issue in the ms draft


No heartburn, just a short note (there is a 99.9% chance that the following
facts were mentioned by others before):

Besides breaking transport independent packaging (e.g. http vs. ftp) this
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). 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.

If the above considerations are of no concern to the ebXML standard (Rik?)
I wholehartedly agree with Dick, Dale, and Nick that the proposed packaging
is the best possible. I just wanted to make sure that the consequences of
the proposed transport mapping are known to the group.

Thanks and sorry for touching this matter once again. 

-Igor Balabine

At 11:28 AM 9/5/00 -0500, richard drummond wrote:
>dick, dale, nick have discussed the mime issue brought up by some in the PoC
>in the last face to face. we believe that the mime package as currently
>indicated in the ms draft is the best one. it clearly fits the mime
>standards. we do not believe double wrapping the mime object is
>appropriate... so unless several of the team have heartburn... we will go
>with it as is.
>
>best regards, rik
>


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Search: Match: Sort by:
Words: | Help


Powered by eList eXpress LLC