Issue 370 - proposed resolution

[<Frederick.Hirsch@nokia.com>]

This email contains a proposed resolution to issue 370 [1],   "SWA
profile: Add processing rules/guidance for SOAP and MIME intermediaries"
 
Issue summary [2]:
 
Add processing rules/guidance for SOAP and MIME intermediaries. How
should various sorts of intermediaries behave (SOAP, MIME) with regards
to SwA profile.

" My concern is primarily with what intermediate MIME processing nodes
are allowed to do in the S/MIME space.  Clearly you want to allow some
intermediate MIME processing (e.g. transfer encoding format
transcoding), so what's OK for an intermediate node to do?  Can an
intermediate node add an S/MIME signature to a MIME message post
wss-swa-profile processing?  Does that signature have to be removed by a
receiving node before wss-swa-profile processing?  What about
intermediate S/MIME encryption?  That obviously has to be removed before
wss-swa-profile processing, but I haven't had a chance to think through
whether any irreversible header munging could occur in that scenario, or
if there's some other way that an S/MIME operation could interfere with
a wss-swa-profile operation."
 
Proposal
-------------
 
Add the following paragraph to  the end of section 2 (MIME processing) :
 
"A MIME processing node SHOULD NOT make any modification to an
attachment that would interfere with SOAP Message Security applied to
that attachment as described in this document.  If SOAP Message Security
is used to sign an attachment, then intermediary MIME nodes MUST NOT
modify that attachment by subsequently applying S/MIME signature or
encryption techniques, since any such modification would invalidate a
previously applied SOAP Message Security signature. (Note that use of
SOAP Message Security encryption of an attachment will make it
impossible to apply such S/MIME techniques to the original attachment.)"
 
 
Thanks

regards, Frederick

Frederick Hirsch
Nokia 

[1]
http://www.oasis-open.org/apps/org/workgroup/wss/download.php/12309/wss-
issues-64.html
 
[2] http://lists.oasis-open.org/archives/wss/200502/msg00054.html, see
#12