Secuirty issues and RE: the mime issue in the ms draft

["Moberg, Dale" <Dale_Moberg@stercomm.com>]

>-
>From: Igor Balabine [mailto:igorb@netfish.com]
>Sent: Thursday, September 07, 2000 2:22 AM
>To: dick@8760.com; richard drummond; Ebxml Transport
>Subject: RE: the mime issue in the ms draft

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

This non-repudiation of route is a pretty exotic security requirement Igor,
and I think a precise definition is needed for those interested in security
to consider whether it should even be a requirement for the security 
specification. 
 
I believe the group is attempting to decouple the basic packaging issues
from 
other packaging issues related to security. The relevance of the
security worry to basic packaging seems to presuppose that there is some
kind
of intrinsic connection that prevents this decoupling. But since S/MIME
security
assumes that the security multiparts can wrap any MIME part as an 
encapsulated or detached object, it is then implied that the issues can be
decoupled. 

I do believe that once the non-repudiation of route is clearly defined, 
it will be possible to find several implementational mechanisms 
using standard security constructs that will do the job.
(Of course, if the job is impossibly defined, we will find
none that do the job...) We should definitely consider
the issue within the security specification if it is agreed to
be a necessary function to support and when we have the precise
definition available that everyone understands in the same way.