Jimmy Zhang (jzhang@ximpleware.com)
Current W3C specs for XML signing and encryption apply XML canonicalization transformation to XML data before crypto operations. Various research papers and commercial implementations have shown that the poor performance of XML signing and encryption is largely caused by XML canonicalization. XimpleWare believes that XML canonicalization's inherent complexity prevents it from being implemented to meet the performance requirement of enterprise-ready SOA infrastructure, that the very notion of signing/encrypting the XML info-set is flawed in the first place, and that W3C should consider enhancing or upgrading the current XML security specifications so that enterprise developers have more (and better performing) choices than currently available.
XML Signature and XML Encryption allow portions of an XML document to be encrypted or signed to ensure the confidentiality, integrity and non-repudiation of the corresponding data. Both specs are based on the concept of XML infoset. In order to sign or encrypt a document, an application usually parses the document into a tree structure, applies canonical transformation to the tree, calculates the hash/cipher value, and finally serializes the tree back into a byte array. The XML canonicalization transformation serves the purpose of producing a unique byte pattern for the XML infoset.
Unfortunately, the real world implementations of XML Signature and XML Encryption have significant performance issues, often referred to as being "deadly slow." HongBin Liu et al. [1] measured the respective latencies of XML processing and crypto operations, and concluded that "it takes less than 10 milliseconds to sign or encrypt up to an array of 100 kilo bytes, but it takes about 100~200 to perform the security operations for SOAP. The length of the XML matters, so does the complexity of XML structure." Satoshi Shirasuna et al. [2] further identified XML canonicalization as being "disportionately time-consuming," and measured that canonicalization alone contributes up to 96% of the total latency (see Table 1).
| (msec) | Phase | (msec) | |
| Signing | 1542.6 |
Conv. To DOM Canonicalization Signature calculation Conv. from DOM Other |
7.7 1391.2 2.2 127.0 14.5 |
| Verification | 1445.8 |
Conv. to DOM Cert. path validation Canonicalization Signature verification Other |
10.2 22.2 1395.5 0.4 17.4 |
Table 1. XML signature break down
But one does not have to rely on empirical evidences alone to appreciate the severity of the problem. XML canonicalization is inherently complex: it consists of around 20 steps ([3][4]), each of which needs to be independently applied to all the nodes contained in the sub-tree. There are additional steps involving name space handling that further exacerbate the problem. Since each of those steps incurs considerable processing overhead, it is only natural to expect the overall "slowness" of canonicalization.
Notice that there is nothing wrong with XML canonicalization per se as it is designed to check the logical equivalence of physically distinct XML documents. But in the context of XML security, XimpleWare believes XML canonicalization is simply too slow for it to suit the intended use of XML signing and encryption.
But the inherent complexity of the canonicalization may only be a symptom of fundamental issues at the philosophical level. To help illustrate those issues, it is worth noting that if processors, memory and networks are infinitely fast, there will be no performance problem for XML signing and encrypting. But in the real world, the success of system design is usually at the mercy of the laws of nature manifested in the form of the constraints, weaknesses and limitations of the basic building blocks of the system. To create a feasible design, one should start with a firm understanding of those constraints, weaknesses and limitations. By looking at the success of the Web and the Internet, it is easy to see that scalable distributed systems are often built from bottom up, one layer at a time. This model is proven successful because in order to build the layer on top, one must heed the properties (both weaknesses and strengths) of the lower layers, making it easier to identify the subtle, but unmistakable boundary that separates feasible designs from science fictions. In contrast, a top-down design (starting from a higher abstraction level and finding its way down to a working implementation) is at a higher risk of being disconnected from the reality, making it more likely to be defeated by often unforeseeable roadblocks and showstoppers.
XimpleWare believes that the real issue is that the introduction of XML infoset (a high-level abstraction) forces the XML signing and encryption to be designed top-down, effectively setting them up to repeat the known mistakes (i.e. ignoring the fundamental constraints and limitations of the digital system). The slow performance is merely the nature issuing silent warning that the "boundary" has been inadvertently crossed.
Because XML security is only a layer in the SOA/WS stack, its performance issue will adversely impact the performance of all the layers above. So far, the adoption of XML security specs seems modest. Therefore, W3C should consider upgrading/enhancing those specs or offer alternatives that are more performant so enterprise developers can have more and better choices.
Below is the summary of XimpleWare's preliminary thoughts on the requirements for the enhanced version, or the alternative, of XML signature and Encryption.
Furthermore, XimpleWare believes the top-down design is largely responsible for technical difficulties of CORBA (assuming objects then building everything else downwards) and the deficiency of DOM (starting with the API, then finding the implementation). Because of it, W3C may consider involving hardware companies and networking companies (both traditionally are more customed to a bottom-up design) to future W3C standardization processes as they bring fresh design perspectives.
The complexity of XML canonicalization is a primary reason why current XML security specs suffer from significant performance problems. The fundamental issue is that the notion of signing/encrypting the info-set forces those specs to be built top-down. The better approach is to build those specs bottom-up, starting with XML. XimpleWare appreciates the opportunity to comment on design of XML security specs and is willing to work with W3C to take them to the next level.
[1] Hongbin Liu, Shrideep Pallickara, Geoffrey Fox Performance of Web Services Security Proceedings of the 13th Annual 13th Mardi Gras Conference, February 3rd to 5th 2005, Baton Rouge, Louisiana
[2] S. Shirasuna, A. Slominski, L. Fang, and D. Gannon. Performance Comparison of Security Mechanisms for Grid Services. Proceedings in 5th IEEE/ACM International Workshop on Grid Computing. 2004.
[3] XML Canonicalization Part I http://webservices.xml.com/pub/a/ws/2002/09/18/c14n.html
[4] XML Canonicalization Part II http://webservices.xml.com/pub/a/ws/2002/10/09/canonicalization.html