RE: [wss-comment] Comments on wss-swa-profile-1.0-cd-01

[<Frederick.Hirsch@nokia.com>]

Brian

Thank you for reviewing the SwA profile Committee Draft. I'll try to
respond, but there are also others on the list who can add something or
correct me if I've got something wrong.

(1) The primary issue you point out is the layering issue. I think there
are a couple of points to consider here.

First, this profile is intended to address the explicit requirement of
being able to secure attachments when an application deals with
attachments explicitly, using SwA. This does not preclude the use of
MTOM. Which is more elegant or appropriate is out of scope.

Second, it is necessary to secure some MIME headers to secure the
attachment properly. The committee felt that certain MIME headers are
exposed to the application, so may be treated as-if at a different layer
than others which may be changed during message transport at the MIME
layer. Hence the profile attempts to limit which MIME headers may be
secured in an attempt to meet the layering goal. I should point out that
we treated the layering as a "goal" but not an absolute requirement.

Although I sympathize with the layering concern, I think from a
pragmatic view this profile outlines a fairly simple way to secure SwA.

We discussed the possibility of copying headers into the primary soap
envelope (e.g. into a signature object as you suggest) and decided not
to do that. We should list this as an issue from public review and
discuss it.

(2) I believe you are correct, we should state in the profile that the
output of both
   Attachment-Content-Only and Attachment-Complete is an octet-stream.
Thanks for pointing this out.

(3) You are entirely correct on transforms, and I think we should change
this. The goal was to clarify the processing and that commonly a base64
transform would not need to be explicitly called out in the transform
chain. Perhaps a non-normative explanation would suffice. Another
potential issue for the TC to discuss. 


(4) The goal is to not *require* XML canonicalization of XML attachment
content to enable this SwA profile processing. This does not preclude
attachment XML canonicalization if an application deems it necessary for
processing (e.g. by an intermediary) and this policy is conveyed to the
appropriate parties (as would be necessary in any case). Is this an
issue for a bit of clarifying language that such XML canonicalization
MAY be performed if participants agree, or am I missing a larger issue?

(5) Yes the assumption was that text/xml attachments would be
canonicalized as type text. 

(6) Again, the issue of layering for encryption assumed that certain
MIME headers are visible to an application interface so should be
treated as content, while others are not and are not included in the
encryption.  

(7) The assumption is that there was no need to discuss interactions
with S/MIME security such secured items can be treated as opaque by this
SOAP Message security - there is no need to go into such attachments to
look at the security mechanisms. The goal here was to use SOAP Message
security with SwA. 

Other TC members may have additional comment. Thanks again, you raise
good points. 


regards, Frederick

Frederick Hirsch
Nokia 

-----Original Message-----
From: ext Brian LaMacchia [mailto:bal@exchange.microsoft.com] 
Sent: Friday, February 11, 2005 12:47 PM
To: wss-comment@lists.oasis-open.org
Subject: [wss-comment] Comments on wss-swa-profile-1.0-cd-01

Dear OASIS WSS TC Members,

Here are my comments on wss-swa-profile-1.0-cd-01, the 23 December 2004
Committee Draft 01 version of SOAP Messages with Attachments (SwA)
Profile 1.0.  In reading this draft I focused primarily on the
signature-related sections, in particular Section 4.4, and how this
draft uses the W3C XMLDSIG Recommendation (IETF RFC 3275).

1) First, a high-level comment: there's a fundamental conflict in this
   spec between the layered processing approach described in Section 2
   (MIME Processing) and the detailed signature construction rules in
   Section 4.4.4.  Section 2 states quite clearly that the goal of this
   specification is to define a layering along the lines of:
      a) Sender SOAP message signature construction
      b) Sender MIME formatting/serialization
      c) Message transfer from sender to recipient
      d) Recipient MIME de-formatting/de-serialization
      e) Recipient SOAP message signature verification
   However, the signature construction rules in Section 4.4.4 violate
   the ordering of (a) and (b) -- they intermix processing steps from
   both the SOAP and MIME worlds.  Section 4.4.4 Steps 1 and 2 state
   that compliant implementations must first *MIME* canonicalize the
   to-be-signed content, then construct the SOAP message, form the SOAP
   signature, and then MIME format the message.  This violates the basic
   layering principle.  It would be much better, and in alignment with
   the XMLDSIG specification, if instead attachment signatures were
   formed as "detached signatures" in accordance with XMLDSIG and then
   the detached signature and attachments packages together into a
   single MIME multipart package. 

   [Note: Doing detached signatures & then packaging is completely
   straightforward for "Attachment-Content-Only" attachments.  For
   Attachment-Complete attachments, though, it's not so straightforward
   because as defined in the spec signing an Attachment-Complete
   attachment explicitly violates the SOAP/MIME layering rules.  There
   seems to be something deeper going on in Section 4.3.2 because I
   don't understand how the MIME headers can have any signficiance if
   the layering principle holds true.  Either the MIME headers are
   strictly a side-effect of the MIME-layer packaging, or they are being
   used in this spec to convey important Attachment-related metadata.
   If the latter is true, it would be more in line with XMLDSIG to put
   this metadata either in the Reference itself or in another XML
   structure within Object elements in main the Signature element.]

   Section 4.4.5 commits the same layering violation as Section 4.4.4,
   but in reverse: after de-MIME'ing the received message the MIME type
   information must be maintained so that the received attachments can
   be properly MIME-canonicalized before doign XMLDSIG Reference
   processing.

   In my view, it should be possible to XMLDSIG sign data that will be
   transferred in MIME attachments without the XMLDSIG engine needing to
   know anything about the MIME transport layer.  Similarly, the MIME
   transport layer should not need to have any awareness of the SOAP or
   XMLDISG-specific nature of the content it (the MIME layer) is
   transferring.  The only touch points between the two layers need be
   the URIs used in References (the cid: URIs).

2) Now for some lower-level comments.  SwA defines two new Transforms
   for the XMLDSIG Transform processing model (Attachment-Content-Only
   and Attachment-Complete).  In the XMLDSIG Transform processing model
   (see XMlDSIG Section 4.3.2.2), Transforms either accept XML Node-sets
   or octet streams; both of these new SwA Transforms appear to be
   octet-stream input Transforms (although it's not explicitly stated).
   However, the output format of the SwA Tranforms is not defined
   because the MIME Content Canonicalization algorithm is not defined
   (Section 4.4.2 says it varies by MIME type).  Since MIME Header
   Canonicalization (Section 4.4.1) outputs a UTF8-formatted octet
   stream, I believe the intent is that the output of both
   Attachment-Content-Only and Attachment-Complete is an octet-stream.
   This needs to be clarified in the specification if it is the intent
   of the spec.

3) In Section 4.4.4 (Processing Rules for Attachment Signatures), Step
   4, lines 346--348 is confusing.  It appears that the intent of this
   MUST NOT is to instruct implementers that they should not include any
   Transforms in the Transform chain that deal with MIME encodings,
   since the MIME encoding/decoding happens at a higher level than the
   SOAP processing.  That's technically correct, but the current wording
   seems to imply that a Base64 Transform could never show up in a
   compliant Transform chain, and that's incorrect.  After the first
   Transform (which has to be one of the two types specified in Section
   4.3) any valid Transform could appear in the Transform chain and
   process the output of the Attachment-Content-Only or
   Attachment-Complete Transform.  So, in particular, it's quite
   possible that a Base64 Transform could show up somewhere in that
   Transform chain.

4) There appears to be a conflict between two parts of Section 3 (XML
   Attachments) which is exacerbated by the canonicalization rules (or
   lack thereof) for text/xml in Section 4.4.2.  Section 3, lines
   155--157, state that "Attachments might also be...targeted toward
   specific SOAP intermediaries...", which implies that attachments
   might have to be processed by intermediaries after the MIME wrapping
   is removed.  However, the following sentence (lines 158---161) says
   that the specification assumes that SOAP attachments need not be
   processed as XML, and specifically not XML canonicalized.
   Furthermore, in Section 4.4.2 we have explicit statements that XML
   attachments do not need to be XML Canonicalized, just "MIME
   canonicalized".  This restriction means XML attachments must be
   treated as binary blobs by intermediaries -- they could not be parsed
   and re-assembled because there's no mandatory canonicalization
   required for XML content before DigestValue hash generation.  (Given
   the interpretation in (2) above, a conforming application could
   include an explicit C14N Transform in the Transform chain to make up
   for this deficiency, but because it's not required for all XML
   content no intermediary is going to be able to depend on being able
   to parse, process and re-assembly XML attachment content.)

5) As a side note to (4) above, note that RFC 3023, the current RFC
   containing the registration for the text/xml MIME type, does not
   define a canonical form for text/xml.  Presumably, then, the
   canonical form for text/xml inherits from the registration for text
   as defined in RFC 2046, which only defines canonical CRLF processing
   for text types.  Given these restrictions, XML attachments by default
   must be handled as opaque binary blobs and it'll be impossible for
   intermediate nodes to do any processing on them absent specific
   indications to the contrary in the Transform chain.

6) I have only read through the XMLENC-related sections briefly, but
   they appear to have similar layering problems/violations.  In
   particular, the fact that MIME headers may be encrypted along with
   MIME content for a particular Attachment means the layering principle
   is explicitly violated for encryption.  (See, e.g., lines 468--469 in
   Section 4.5.2.)  According to Section 4.5.2, a conforming
   implementation would need to SOAP-format (but not encrypt) the
   to-be-sent message, then MIME-format the message, then XMLENC-encrypt
   soem MIME attachments, then re-format the (now-encrypted) MIME
   attachments, then re-format the SOAP message.  Again, I would ask why
   MIME is bring treated as anything more than a packaging mechanism for
   a collection of XML objects that internally have signature &
   encryption relationships.

7) There is no discussion in this spec about the relationship between
   SwA signatures & encryption and S/MIME signatures & encryption.  What
   are the processing rules for combining SwA & S/MIME signatures (since
   a signed SwA message might be re-signed at the MIME level by a MIME
   intermediary)?

In summary, I'd strongly recommend that the WSS TC re-consider the
mixed-mode, cross-layering approach they've used for signature
generation and instead consider a cleaner architecture that performs
SOAP, XMLDSIG & XMLENC processing first, without any reference to the
MIME layer, and then uses the MIME layer strictly for transport.

I'd be happy to answer any further questions the TC has about these
specific comments or the XMLDSIG Recommendation in general.

                         --Brian LaMacchia
                           Co-author, XMLDSIG
                           bal@microsoft.com