One of the most thought-provoking notes on XML security is Peter Gutmann’s piece on Why XML Security is Broken. As I started thinking about security around REST APIs, I happened to stumble upon James Clark’s Bytes not infosets which led me to Peter Gutmann’s note. This writeup confirmed my experience that web services security is overly complicated and complex to implement and support. It can be made to work, however, and this is where I disagree with Peter Gutmann. His note also explains why web services security is so tightly coupled with the underlying XML processing system (i.e. the web services stack) that choice of using a particular web services stack ties you into using a supported (if there is one) security implementation. This is unlike HTTP-based security where code processing requests and responses is almost always independent of the security layer.
As James Clark points out, XML/web services security takes the infoset point of view of XML. In this view, the security is applied to XML at the abstract level and not how it is represented as bytes over the wire. However signatures and encryption work on raw data and not on abstract models. So, the XML needs to be serialized into raw bytes.
This is not a problem in itself unless you want to put back the data + signed data or the encrypted data back into an XML envelope. To make sure that the recipient can verify the signature or decrypt the data into XML, both the sender and receiver must use the same form of serialization, and this brings us into XML canonicalization.
At a high-level, for signing a piece of XML and include it into the XML envelope involves the following:
Looking at these steps, if you are worried about performance, you should be. Canonicalization adds an extra layer of overhead. To my experience, canonicalization rules are also complex to implement, and it is easy to get the implementation wrong.
The costs on the receiving end are similar.
But wait a sec? Why do we have to put back the signature or encrypted into an XML envelope. The only argument for doing so is to keep everything together in XML and not depend on how it is stored or transported over the wire. In the case of SOAP based web services, it is to keep the security layer independent of the transport. That is it. The core reason is to maintain transport agnosticism. As I have argued before, trying to keep the messages agnostic of the transport introduced a lots of complexity to web services. Security, as suggested by web services specifications, is one more problem. The point is, why depend on the infoset view when it does not lead to the most optimal solution? Why invent and stick to some pedagogic arguments if they make things more complex to implement and support? Makes no sense.
This complexity would give away if (a) we sign bytes, and (b) carry the signature without an envelope.
The signature could be carried via a transport level header or a MIME attachement. Of course, the downside would be that you can’t sign arbitrary elements within the XML data. In fact, most web services security APIs are designed to let you sign arbitrary elements. But is that flexibility really necessary? I would argue that keeping runtime simplicity and efficiency is more important.
