Re: FW: [wss] WSS SwA profile Issue 364 - close

[Anthony Nadalin <drsecure@us.ibm.com>]

+1

Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122
<Frederick.Hirsch@nokia.com>

<Frederick.Hirsch@nokia.com>

05/01/2005 11:58 PM

To	<wss@lists.oasis-open.org>
cc
Subject	FW: [wss] WSS SwA profile Issue 364 - close

---

From: ext Brian LaMacchia [mailto:bal@exchange.microsoft.com] 
Sent: Friday, April 29, 2005 2:24 PM
To: Dana Kaufman; Hirsch Frederick (Nokia-TP/Boston); wss@lists.oasis-open.org
Cc: hlockhar@bea.com; JRWeiland@US.MED.NAVY.MIL
Subject: RE: [wss] WSS SwA profile Issue 364 - close

The issue, as I pointed out below, is that there are implicit assumptions here that the node creating the SwA message knows the XML behavior of all the intermediate processing nodes that a message is going to go through, and every intermediate processing node knows the types of the MIME messages (SwA-signed or not) that are going to pass through it.  Neither of these assumptions is reasonable in my opinion and the consequence is that I have to program defensively and encode all of my XML attachments into opaque blobs.
 
Let’s look first at the behavior of the sender node, which is constructing a SwA message where one of the attachments is XML.  If I, as the sender, do not know the XML behavior of every intermediate node my message is going to go through, then it is possible that some intermediate node will shred and re-assemble my XML attachment in a semantically-neutral way as it processed my message.  As the sender I have to assume such a transform is possible, and if I don’t defend against such transformations my signatures could fail to verify on the other side.  Therefore I can either (a) explicitly XML canonicalize my XML attachment using some XML canonicalization algorithm (C14N, Exc-C14N, or something else that preserves the semantics content), or (b) turn my XML attachment into a Base64 blob (or some other opaque form) so it won’t look like XML to an intermediate node.  If (a) is the right thing to do, then the spec should just require that and guarantee interop.  If (b) is the right thing to do then the interop story sucks for XML attachments.  Implementations that perform neither of these two protections options for XML attachments are flawed because they might never be able to send an XML attachment across a set of intermediate nodes in a way that keeps the signature verifiable.
 
Now let’s look at the situation faced by an intermediate MIME-processing node, one which is XML-aware and does something intelligent with XML attachments that pass through it.  If it is ever conceivably possible that this intermediate node could receive an SwA message, with a raw binary signature over an XML attachment, then this intermediate node can never perform legal, semantically-neutral XML processing on an attachment because that attachment might be a signed SwA attachment and doing the processing would break the signature.  The only thing I might be able to do in my intermediate node is make my implementation explicitly try to detect SwA-formatted MIME messages and change my behavior when such a message arrives for processing.  *Every* XML-aware MIME processor would have to special-case SwA messages.  That’s not a reasonable expectation of XML-aware MIME processors.
 
If you’re going to sign XML data you need to do so using an appropriate XML canonicalization algorithm.  Yes, the perf on C14N and Exc-C14N isn’t great, which may mean you need to come up with an alternative XML canonicalization algorithm that is lighter weight.  But you can’t just wave your hands and pretend that XML semantically-neutral rewriting isn’t going to happen somewhere without the sender’s explicit knowledge.  The sender doesn’t know that, and the intermediate nodes shouldn’t have to special case their handling of this format because it doesn’t comply with the standard rules for signing XML content.
 
The XMLDSIG standard discusses the need for XML canonicalization in Section 7.0 (http://www.w3.org/TR/xmldsig-core/#sec-XML-Canonicalization).  In particular, I would highlight the following quote from paragraph 3 in that section:
 
“It is possible for an isolated XML document to be treated as if it were binary data so that no changes can occur. In that case, the digest of the document will not change and it need not be canonicalized if it is signed and verified as such. However, XML that is read and processed using standard XML parsing and processing techniques is frequently changed such that some of its surface representation information is lost or modified.”
 
Draft 17 assumes that XML attachments are not going to be read and processed using standard XML parsing and processing techniques at intermediate nodes.  I believe that’s an incorrect assumption and needs to be fixed.
 
                                                            --bal
 
P.S.  I also fail to see how requiring XML canonicalization “makes it more restrictive.”  How is requiring canonicalization restrictive?
 
P.P.S.  Frederick, I’m not sure whether I’m allowed to post to the wss mailing list (I’m a TC Observer); in the past postings I have sent to the list have not shown up there (I’ve had to have someone forward them for me).  If this message doesn’t go through automatically would you please forward it for me so everyone will be made aware of the problems I see with Draft 17’s language?  Thanks.

---

From: Dana Kaufman [mailto:dkaufman@forumsys.com] 
Sent: Friday, April 29, 2005 10:48 AM
To: Frederick.Hirsch@nokia.com; Brian LaMacchia; wss@lists.oasis-open.org
Cc: hlockhar@bea.com; JRWeiland@US.MED.NAVY.MIL
Subject: RE: [wss] WSS SwA profile Issue 364 - close
 
I agree with Frederick that we should close this issue as noted on the TC call.  Adding cannonicalization makes it more restrictive, and impacts performance.  If you want xml c14n for the xml attachments, you can just add another transform to the signature, which is fully supported by the current draft specification.
 
Dana S. Kaufman
VP of Product Management
Forum Systems, Inc.
Tel: (781) 788-4232
E-Mail: dkaufman@forumsys.com
Visit http://www.forumsys.com

---

From: Frederick.Hirsch@nokia.com [mailto:Frederick.Hirsch@nokia.com] 
Sent: Monday, April 25, 2005 2:55 PM
To: bal@exchange.microsoft.com; wss@lists.oasis-open.org
Cc: hlockhar@bea.com; JRWeiland@US.MED.NAVY.MIL
Subject: RE: [wss] WSS SwA profile Issue 364 - close
 
Brian
 
I believe draft 17 reflects the current TC opinion regarding conveying XML attachments. I outlined the rationale for this on the TC call and there was agreement on the call. 
 
I think it is an overstatement to say that this means XML cannot be conveyed in attachments. First of all, TC members informed me that most implementations would not be expected to process the XML in attachments (unless intended at the application layer), so this should not be an issue for these implementations. For those implementations that find this an issue, it is possible to encode the attachment so it is not processed (e.g. base64).  As noted in the document, many do not want to require the overhead of canonicalization and I believe there was strong opinion on this point.
 
As editor I will rely on the direction of the TC, which I believe has been clear. If the TC believes a vote is necessary, I would request a motion that "The TC adopt the resolution to issue 364 as provided in draft 17 of the SwA profile".
 
I would like to request that TC members review this issue in advance of the next WSS meeting on 3 May so that it may be closed at that meeting. Please send any discussion to the WSS list in advance so that the TC can make an informed decision.

regards, Frederick

Frederick Hirsch
Nokia

---

From: ext Brian LaMacchia [mailto:bal@exchange.microsoft.com] 
Sent: Thursday, April 21, 2005 4:48 PM
To: Hirsch Frederick (Nokia-TP/Boston); wss@lists.oasis-open.org
Cc: hlockhar@bea.com; Weiland, John R. NMIMC GS
Subject: RE: [wss] WSS SwA profile Issue 364 - close
Hi Frederick,
 
I haven’t seen any substantive discussion of Issue 364 on the mailing list, nor in the minutes of the bi-weekly conference calls, so I am somewhat surprised by the TC’s reversal on this issue as reflected in Draft 17.  It seems to me that the language in Draft 17 makes the situation worse – it basically says that unless the node constructing the message has direct knowledge of the processing behavior of every intermediate node, XML attachments cannot be attached and transported as XML. Working under this model, a general-purpose WSS SwA message construction library would have to assume that an intermediary *might* be XML-aware and thus, by default, encode all XML attachments into some opaque format.
 
Note also that because no *specific* encoding format is required for encapsulated XML attachments, it will be impossible for smart intermediaries that have knowledge about the “XML safeness” of their downstream links to decode the encoded XML attachments.  This essentially pushes XML attachment decoding to the ultimate receiving endpoint.  
 
Are details of the TC’s reasoning behind the decision to reject XML canonicalization for signed XML attachments available anywhere?  I continue to believe that WSS SwA has a problem if it does not require XML canonicalization of XML attachments and that the language in Draft 16 was the proper way to resolve Issue 364.  
 
Thanks,
 
                                                            --bal
 
P.S. I note that in the minutes of the 04/19/2005 conference call that John Weiland just sent out, Issue 364 is listed as having been closed during the call.  I assume that, given your e-mail of this morning, the minutes are in error and the Issue remains “pending review”.

---

From: Frederick.Hirsch@nokia.com [mailto:Frederick.Hirsch@nokia.com] 
Sent: Thursday, April 21, 2005 2:23 AM
To: wss@lists.oasis-open.org
Cc: hlockhar@bea.com
Subject: [wss] WSS SwA profile Issue 364 - close
 
I believe issue 364 should be closed [1]. It was marked pending at the meeting before last (5 April) and was resolved by reverting to the approach of the Committee Draft, ie. that attachments are not to be XML canonicalized.
 
I have received no additional feedback since 5 April, so I believe this can be closed on the next call.
 
If this incorrect please send an email to WSS list before the next call.

regards, Frederick

Frederick Hirsch
Nokia
[1] http://www.oasis-open.org/apps/org/workgroup/wss/download.php/12309/wss-issues-64.html