I agree with you that the XML gateway appliance vendors will benefit from widespread adoption of WS-Security. <grin>
I'm not an expert in security, although I do know enough to know that it's a remarkably complex topic. The security gods have reached the conclusion that the best way to ensure end-to-end security and to reduce security vulnerabilities when dealing with attachments is to make them part of the SOAP message infoset. The documents I cited can tell you why -- but you need a pretty deep understanding of security threats and countermeasures to truly understand them. (I'm definitely on shaky ground when reading them.) XML Signature requires XML Canonicalization because you absolutely need to make sure that not one bit in the message changes to replicate and validate a signature. That's just the way it is. The message may get compressed or chunked or whatever in transit, so you have to be able to reconstruct it exactly. Only canonicalization can ensure perfect reconstruction. Anne On 7/28/05, Dennis Sosnoski <[EMAIL PROTECTED]> wrote: > Thanks for the pointers, Anne, I'll check out the documents. > > As to the issue of attachments not being part of the Infoset - honestly, > that seems a much cleaner approach to me than making them look like > base64 encoding, as done by MTOM. WS-Security (which in turn builds on > XML Signature, which uses XML Canonicalization) is one of the most Rube > Goldberg-ish contraptions in the history of technology. It's the > equivalent of writing your data out in longhand on a whiteboard, taking > a Polaroid of the whiteboard, signing that, and enclosing it with the > transmission. The main beneficiaries of WS-Security would seem to be the > manufacturers of XML appliances, which suddenly have a huge potential > market. > > IMHO there's no reason why WS-Security couldn't have been designed with > attachments in mind, and implemented the sensible approach of just > encrypting or signing the binary format directly. > > - Dennis > > Anne Thomas Manes wrote: > > >I believe that the vulnerabilities are outlined in the WS-I Security > >Challenges, Threats and Countermeasures document > >(http://www.ws-i.org/Profiles/BasicSecurity/SecurityChallenges-1.0.pdf). > >You might also check the OASIS WS-Security Attachment Profile draft. > > > >The same security vulnerabilities apply to WS-Attachments and DIME. > >The gist of the problem is that SwA and WS-Attachment attachments > >aren't part of the SOAP Infoset and therefore aren't protected by > >WS-Security. MIME is slightly more vulnerable because you can't secure > >the MIME headers except via SSL/TLS. > > > >I think Microsoft's point, though, is that there's no incentive to > >implement support for SwA because it is being superceded by MTOM. > > > >Anne > > > >On 7/28/05, Dennis Sosnoski <[EMAIL PROTECTED]> wrote: > > > > > >>Anne Thomas Manes wrote: > >> > >> > >> > >>>Unfortunately, Microsoft does not and will not support SwA, therefore > >>>Microsoft does not and will not support the WS-I Attachment Profile > >>>1.0. (SwA has some inherent security vulnerabilities, so I understand > >>>Microsoft's position on this point.) > >>> > >>> > >>> > >>Can you supply any pointers on the SwA security vulnerabilities, Anne? I > >>didn't find anything in a quick search. > >> > >> - Dennis > >> > >> > >> > > > > > > >
