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.
- 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.
- 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.
- Applications using these methods would include point to point,
high performance transactions or messages, requirements for low
processing overhead, memory, etc.
- 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