Efficient XML Interchange (EXI) with XML Signature and Encryption: Reuse and Opportunity

Stephen D. Williams - sdw@lig.net / swilliams@hpti.com

EXI Group Position:

This position paper outlines key issues with regard to XML signatures and encryption as applied to Efficient XML Interchange (EXI).

The EXI format, as defined by the XBC and EXI working groups, is a compact, high performance, low resource representation of the XML Infoset.  An initial, baseline specification was recently published.  EXI is meant to be usable in nearly all current uses of XML, but also to greatly expand the "market" for XML technology by providing an alternative for the many applications that are too performance sensitive to use XML competitively now.  Many applications, including this broader set, can benefit from or require signatures and encryption.  While in some cases the only completely functional solution will be to convert to text-based XML for canonicalization and XML signature and encryption, in performance-oriented applications this will not be appropriate. 

Two different levels of EXI-specific signature and encryption seem to be indicated by use cases and perceived applications.  These options are explicitly for groups of applications or environments where EXI is pervasively implemented, although at any point XML can be produced for other applications.
  1. Creation of a more or less direct equivalent of existing XML signature and encryption specifications, but tailored and translated for the EXI format rather than text.  This might mean an EXI-level canonicalization and certainly means defining a standard fashion of envelope, self-containedness, etc.
  2. Creation of a lightweight method of signing and encryption that provides fewer features than a full canonicalization / signature and encryption stack with far less processing overhead.  This mode would not have the roundtrip-through-an-application resilience of XML Signature, or at least not in the same fashion, but would provide signature and encryption function using the same semantics as much as possible.  Lightweight signing and encryption avoids severe overhead while providing much more than ephemeral session encryption.  A lightweight signing mode can be modeled as signing, validating, and encrypting a block of bytes that are resigned if changed.  While not as powerful as full XML signature, this fits many application use cases and can be made very efficient.
    1. Applications using these methods would include point to point, high performance transactions or messages, requirements for low processing overhead, memory, etc.
    2. Characteristics of these methods include little or no conversion and pre-processing.
An issue that, while already weakly existing in the form of schema information [1], is an important consideration for EXI is schema-informed encoding.  EXI allows data instances to be encoded relative to information that has been externalized by sharing a schema between the encoder and decoder.  (Other methods of generating and sharing externalized information have also been proposed.)  This issue must be addressed directly in signing and encryption at the EXI level. 

XBC and EXI working groups have deferred to XML Signature and Encryption working groups and specifications for signing and encryption while noting the significant burden certain applications would have to endure to strictly follow standard practice.  It is important to support widespread compatibility but also to address the widest range of applications with a small, unifying set of solutions.  The intersection of EXI with signing and encryption should be considered with respect to the broad range of applications that are being addressed by EXI.

Stephen Williams - High Performance Technologies, Inc. position:

One possible solution to provide flexible and automated sharing of schema or schema-like information that is being discussed is generation of  a representation of encoder grammar and table state that can be called, loosely, a "compact schema" instance.  This could be signed and/or encrypted, together or separately from a data instance.  One clear design would be to send (or store) a message with the common, redundant schema-like information and then send a series of messages that have been encoded relative to it.  Somewhat related is the concept that an encoding option header, or possibly any level of information such as a message template, could be in a "parent" document that is used to produce a relative, "delta" instance.  The relationship is one that would become important in terms of signature and encryption.

By allowing signing of individual elements of a canonical XML instance, existing XML Signature specifications allow a document to travel through a workflow, potentially through software of different origin, gaining signed data in the process.  With support of deltas and lightweight signing and encryption, a different model of distributed collaborative data accretion in an application workflow is possible.  In this model, a base document is created and signed.  Additional participants make changes as deltas to the original document and signs those instances. 

An unstudied, but possibly useful question is whether EXI would be a better format for digital certificates and related messages that are in BER/DER/PER format.  EXI is at least as compact as PER in most cases while being directly mapped from the XML Infoset.  Using the same encoding and decoding methods for both the content and PKI certificates would likely reduce code footprint and complexity.  A related question is whether there are ways to reduce the size of signatures, keys, and other XML Signature and Encryption constructs either in the general sense or in deliberately weakened usage applications.

[1]  XML-Signature Syntax and Processing, http://www.w3.org/TR/xmldsig-core/
See note on 3.1.2 Signature Generation.

swilliams@hpti.com http://www.hpti.com Per: sdw@lig.net http://sdw.st
Stephen D. Williams 703-371-9362C 703-995-0407Fax 20147 AIM: sdw