RE: Issue 370 - proposed resolution

["Brian LaMacchia" <bal@exchange.microsoft.com>]

Hi Frederick,

I believe this proposal for resolving Issue 370 suffers from a similar
problem to the one I described with the proposal for resolving Issue 364
in Draft 17: it proscribes legitimate S/MIME-related behavior of
intermediate MIME-processing nodes.  Sending nodes constructing SwA
messages have no way of knowing whether intermediate MIME-processing
nodes will perform any S/MIME operations, and intermediate
MIME-processing nodes can't be expected to special-case handling of SwA
messages over other types of MIME messages passing through them.

It is certainly possible, and well within the realm of possibility, that
two intermediate MIME-processing nodes would use S/MIME encryption and
digital signatures to secure the link between them.  Now, to the extent
that intermediate S/MIME processing by one intermediate node is
undone/removed by a later node downstream (as in the case of S/MIME
securing a MIME tunnel) then the SwA communication from sender to
ultimate recipient should not be impacted.  Where SwA is likely to be
impacted is if intermediate MIME processing nodes add S/MIME digital
signatures to the MIME message that persist until the message is
SwA-processed by the ultimate receiver.  (Imagine an intermediate
MIME-processing node adding a timestamp to every MIME message passing
through it, for example.)

If the SwA receiver receives a message with an intermediate signature
attached, then either (a) the entire message has been "wrapped" inside
an S/MIME signature, or (b) just some of the attachments have been
signed (I *think* this is legal -- what the intermediate node is doing
in this case is rewriting one of the MIME sub-parts of the SwA
multipart/related to be an S/MIME message).  In case (a) I think all
that the receiving node is going to need to do is unwrap the S/MIME
signature itself (whether clear-signed or application/pkcs7-mime) and
then SwA-process the internal wrapped MIME content.  In case (b) I'm not
sure what to recommend because I don't think you can tell necessarily
whether the signature was applied to the attachment before or after the
SwA message was created.  (It's possible that the SwA WSS signature was
applied to the signed attachment, or it could be that the attachment
itself was signed/counter-signer later down the MIME processing chain.)

					--bal

-----Original Message-----
From: Frederick.Hirsch@nokia.com [mailto:Frederick.Hirsch@nokia.com] 
Sent: Tuesday, April 26, 2005 4:54 PM
To: wss@lists.oasis-open.org
Cc: Brian LaMacchia
Subject: Issue 370 - proposed resolution

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