By Ed Simon, XMLsec Inc. <http://www.xmlsec.com>
2009-01-08
I have reviewed the EXI use cases covered in “http://www.w3.org/TR/xbc-use-cases/” [1] with regard to their impact on the requirements for the next version of XML Signature and XML Encryption.
Each use case presented is associated with properties classified as the following (copied from [1]):
Must Have: This is the set of properties which must be supported for a format to be adopted in the use case domain. This is intended to be a high bar in that an unsupported "must have" property would not simply make a format undesirable but actually unusable.
Should Have: This is the set of properties which are important, but not critical, to the use case. A format which did not support "should have" properties would be significantly less desirable than one that did. However, formats not supporting "should have" properties would still be usable for that use case.
Nice To Have: This is the set of properties which are not important, but supporting them brings some benefit to the use case. However, the benefit is generally minor and would be traded off to support "should have" or "must have" properties for that use case.
Included among the properties are Signable and Encryptable. Signable is defined here:
http://www.w3.org/TR/xbc-properties/#signable
and Encryptable is defined here:
http://www.w3.org/TR/xbc-properties/#encryptable
This use case describes the need for EXI between consumer television devices (TVs, PVRs, etc.) and infrastructure servers. Neither Signable nor Encryptable are mentioned in the property lists for this use case. Though I will not dwell on the topic here, I wonder if issues such as user privacy (e.g. the choice of what shows they seek additional data) and digital rights (either of the metadata itself or metadata pertaining to digital rights of the actual TV data) might not suggest some possible need for signatures and encryption.
This use case describes the need for EXI to transfer large amounts of binary data (arrays of floating point numbers) describing data from seismic measuring and well logs. Neither Encryptable nor Signable are identified as potential properties.
This use case deals with the potentially large and complex 3D graphics content that needs to be efficiently transferred and processed over the Web by a variety of devices. Both Signable and Encryptable are listed as Must Have properties for the following reasons (excerpted from [1]):
1) “Digital signature and encryption compatibilities are also important for protecting digital content assets.”
2) “Security: Compressed binary encoding will optionally enable security, content protection, privacy preferences and metadata such as encryption, conditional access, and watermarking. This corresponds to the Signable property.” (I would say they also apply to the Encryptable property.)
This use case investigates the ability for “small devices” to request web services and to respond to them. “Small devices” are characterized by limited processing power, limited memory, limited battery power and limited bandwidth operating in a high-latency, potentially pay-per-byte network. The use case identifies Encryptable as a Nice To Have property (no explanation given) and does not list Signable.
I would be interested to find out why web services for small devices would not have the same security needs (including both signing and encryption) as web services for general devices.
This use case focuses on enterprise intranet web services with the view that the move to Service-Oriented Architecture-based web services in the extranet will motivate a similar transition within the intranet if the drawbacks of increased processing power requirements and efficiency can be alleviated. From [1], “Intranet Web services differ from Internet Web services especially in the areas of deployment and security: deployments are easier to manage and security is typically defined by a single domain. The requirements for intranet systems are somewhat different from those for Internet systems, permitting the use of certain optimizations in the former which would be difficult or simply impossible to implement in the latter. ”.
Both Signable and Encryptable are listed as Must Have properties for presumably the same reasons they are required by inter-enterprise web services.
This use case describes XML-based document formats and the need for an efficient means of enabling dynamic, distributable authorhship and readership of these documents. The need for signatures and encryption is discussed extensively though, interestingly, Signable and Encryptable are only listed as Should Have properties. Of particular interest is the note that “The conversion of a document between different encodings must preserve all information in the document, including digital signatures.” which would presumably require some sort of canonical encoding transform to make the signature verifiable even when the document is presented in a different encoding.
It should also be noted that [1] was produced in 2005 and there has been much work in the area of XML-based document formats (e.g. Open Document Format and Office Open XML) that support digital signatures.
FIXML (Financial Information Exchange Markup Language) is, as its name suggests, intended for the exchange of financial information within the securities industry. In an attempt to optimize the original FIXML, an alternate version called TO-FIXML (Transport Optimized FIXML) was introduced which provides a more succinct XML syntax (shorter names, use of attributes rather than child elements where possible) was introduced however an EXI-based alternative would appear to be even more advantageous. (I note that if one wants to introduce foreign namespaces (e.g. an XML Signature), then TO-FIXML would have little choice but to use its standard structure. On the other hand, with EXI, FIXML would meet its goals with TO-FIXML and not be negatively impacted by the non-FIXML-optimized content such as XML Signatures.)
Historically, FIXML-related work was one of the prime motivators for the first version of XML Signature. [1] identifies Signable as a Should Have property and Encryptable as a Nice To Have property.
This use case discusses the efficient transfer and processing of multimedia XML documents (e.g. graphics, maps) to mobile handsets. Neither Signable nor Encryptable are listed as relevant properties.
Though it may not be evident from the title, this use case is focused on business communications over extremely limited bandwidths with sufficient processing power at either end. As such compression is a significant requirement. Encryptable and Signable are listed as Should Have properties though it is not evident from the description in [1] whether there are reasons for their inclusion beyond the common ones for intra/inter business communication.
XMPP (Extensible Messaging and Presence Protocol) is intended for use in situations where many users are exchanging many relatively short and simple messages with each other. Though XML has proven itself to be a convenient format, a binary-based format would appear to be optimal given the large volume of messages and their brevity.
Encryptable is listed as a Should Have property (presumably for privacy reasons) and Signable is listed as a Nice To Have property (presumably for basic message authentication and integrity purposes).
This use case describes the need for efficient querying of documents in persistent stores. It is accepted that whatever format the document was in when it was stored, that XML-based queries (e.g. XPath and XQuery) will be used to access the document and hence the need for an XML-compatible working format. Though there is no specific discussion of security, Signable is identified as a Must Have property and Encryptable is identified as a Should Have property.
This use case discussed large, complex documents that represent the state of a collection of knowledge and/or a business process. These documents are distributed and passed among peers. Encryptable and Signable are listed among the Should Have properties.
This use describes information processed by Layer 7 application-oriented routing devices. These routing devices require an efficient means of inspecting the information they are routing and, for some applications, security is a concern. From [1], “Message security may also be a concern in routing and publish subscribe systems. An alternate XML format which supports Signable and Encryptable properties in an efficient manner is indispensable in these types of scenarios. In many situations any part of the content may be used to make routing decisions, so those parts need to be decryptable by the routers making those decisions. In this case it is necessary to be able to decrypt only fragments of the message, and the needed level of fragmentation may not be known beforehand. It is important to note that mere compatibility with existing XML Signature and XML Encryption Recommendations without considerable advances in the security processing speed of text XML implementations will not be sufficient.”.
This use case is essentially similar to the previous one except that the messages are SOAP messages for Web Services. The comments from the prior use case apply here.
This use case discusses the need for EXI in military environments. Such environments include practically the challenges presented in the other use cases – a variety of content types, processing capabilities, bandwidth availabilities, etc.
Despite the obvious importance of security, the authors of this use case chose to include neither Encryptable nor Signable in the list of properties for the following reason: “We have included properties we believe are in scope for a binary XML standard and have omitted properties they reinvent or otherwise duplicate functionality at other layers of the technology stack. For example, security features were omitted from the list of binary XML properties because they already exist in the XML technology stack (i.e., XML signatures and XML encryption). To the extent possible, we would like to reuse existing XML technologies with binary XML instead of developing duplicate capabilities specific to binary XML. This will result in a clean separation of concerns, increasing interoperability and reducing the cost and complexity of binary XML.”.
This use case covers the low power, low bandwidth environment of remote sensors. Like the preceding military use case, neither Encryptable nor Signable are mentioned as properties because they are assumed to be handled elsewhere in the protocol stack. To quote: “The communication format should not add any additional cost to encrypting/decrypting and signing/verifying sensor reports and commands.”.
This use case is characterized by vast computing power, distributed sytems and users, and large amounts of data that must be “efficiently produced, used, and shared”. No specific mention of encryption or signatures is made and neither Encryptable nor Signable appear in the properties lists.
The purpose behind this report was to review the EXI use cases as they pertain to the current work on XML Signature and XML Encryption. In the above reviews of each use case, I have reiterated and occasionally commented on the view the use case authors took with respect to the application of encryption and signatures. It is apparent, and quite understandable, that different authors took different approaches in their consideration of the need for for encryptability and signability. If the use case document was being redone, it may have been useful to evaluate the need for encryptablity and signability using the question “Do you expect that there will be scenarios where the lack of encryptability or signability will prevent adoption by significant players”.
In my perspective, admitting that I am, inter alia, a security consultant, I have a hard time seeing why signability and encryptability wouldn't be requirements in each use case. It may be true that there are common scenarios within the use cases where neither signability nor encryptability is required but for each use case, I can also see scenarios where they are.
The real question though is not so much whether signability or encryptability is needed but, where they are needed, how should XML Signature and XML Encryption work with EXI. As a starting point, I think this comment in the “Content-Based Routing and Publish Subscribe” use case is well said: “It is important to note that mere compatibility with existing XML Signature and XML Encryption Recommendations without considerable advances in the security processing speed of text XML implementations will not be sufficient.”. I believe this reflects the same thought about the potiential need to “Developing a design and protocol for an EXI-formatted XML Signature and XML Encryption for signing/encrypting EXI-formatted data.” that I mentioned in a post [2] to XML Security discussion boards.
[1] XML Binary Characterization Use Cases, W3C Working Group Note 31 March 2005, http://www.w3.org/TR/xbc-use-cases/
[2] http://lists.w3.org/Archives/Public/public-xmlsec/2008Sep/0005.html