[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]