RE: Comments and questions on EXI and its implications regarding XML signature

Hi Juan Carlos Cruellas and XMLSec fellows,

Thank you very much for taking time to review the EXI draft from
the perspective of XML Security requirements, which is invaluable
for the success of EXI format.

Regarding the question of the string table feature, it is worth
noting that string tables are neither embedded into EXI stream nor
are exchanged in any form between EXI processors. Instead, it has
initial entries and grows over time during the processing of an EXI
stream. The entries are reset to the initial state after processing
each single EXI stream. Both the initial entries and the way
it grows are both defined in the specification.

You might want to take a look at appendix D which describes the
initial, static entries of each string table partition.
http://www.w3.org/TR/exi/#initialStringValues

Additionally, when schemas are used to inform the grammar, the
defined target namespaces and the uris used in wildcard terms
are appended to the uri partition. Similarly, the local-names of
elements, attributes and types are appended to their respective
local-name partitions, the partition of which is identified based on
the target namespaces associated with the local-name, again
when schemas are in use. These behaviour is described in more
detail in section 7.3.1.
http://www.w3.org/TR/exi/#stringTablePartitions

The other issues you brought up are both related to canonical
representation of data in the context of dsig.

We have been emphasizing that, the same canonicalization
mechanism can be applied to EXI, by treating it as merely a
alternative serialization of infoset. As we provide infoset mapping
in the specification (appendix B), given an EXI stream, one can
treat an EXI stream as an instance of infoset, then apply
XML canonicalization to obtain a character sequence representing
a canonicalized XML suitable for signing. It's a good point
that you mentioned about the use of fidelity options. To fully
support infoset, you'll need to enable maximum fidelity, which
is to preserve comments, pis, dtd, prefix and lexical values.

As mentioned above, there can be a set of encoding conventions
that can be applied to EXI, in order to define canonical encoding of
EXI streams. There are certain leeway of decisions that EXI
encoders can make to generate different sequence of octets
while essentially representing the same data, the example of
which include attribute order in schema-less grammar, namespace
declaration order, etc. EXI spec does not dictate a single way to
do such things, by virtue of implementation freedom. We believe
that it's very useful to have a separate specification that describes
canocal encoding of EXI that dictate a single way to do things
wherever EXI specification leaves some leeway for encoders.
The primary benefit of defining canonical EXI encoding is processing
efficiency. You just need to use canonical method of encoding to
get EXI stream, then it's the thing you can send and sign on at once.
There's no need for infoset transformation for the purpose of
canonicalization. You pointed out that fidelity setting makes
a variety of representatin for the same information. Fidelity
options are part of EXI header, so the canonical EXI stream
should contain fidelity option settings in the EXI header. The
canonical representation is then in terms of the fidelity settings.
The same fidelity setting is managed both at the sender now,
because it is part of the EXI header.
As for xml:base and xml:lang, a care would have to be taken to
make sure the canonical EXI encoding includes their respective
proper values.

Regards,
The EXI WG





-----Original Message-----
From: public-exi-request@w3.org [mailto:public-exi-request@w3.org] On Behalf Of Juan Carlos Cruellas
Sent: Monday, April 14, 2008 1:27 AM
To: public-exi@w3.org; XMLSec; Juan Carlos Cruellas
Subject: Comments and questions on EXI and its implications regarding XML signature


Dear EXI members,

My name is Juan Carlos Cruellas, and I am a member of the XML Security
Maintenance Working Group. Some time ago I took an action to "review EXI
with respect to correct XML Security usage". After reading the part
devoted to the encoding of xml documents / fragments whose syntax is not
specified by a xml or dtd, I have a number of comments that I would like
to share with you so that you could confirm or correct.

Please note that these comments refer to the second version not to the
latest issued a couple of weeks ago.

1. EXI allows to shorten or optimize the encoding of literals that are
repeated through the document, be they element or attribute values,
local-names elements, namespace prefixes or namespace uris.
If such option is set then EXI processors assign to the literals short
codes that are matched to the literal values in tables that are
populated in thte EXI stream. EXI spec uses the verb "populated"
but I was not able to clearly identify how these tables should be populated.
Does this means that this population is out of the scope or is it assumed that the table
is also part of the EXI stream?. Is this
I mention this because this could be a potential issue if security had to be applied to
the EXI stream.


2. My understanding is that exi does not provide a "canonical" encoding
of a xml document /fragment: the fidelity options, which deal with
preservation / not preservation of certain components of the xml
document / fragment seems to me that allows different encodings. Also, I
do not remember any mention to the order in which attributes and
namespaces should be encoded in the exi stream. Again, the reason for
mentioning this is that if such a canonical encoding is not defined then
two different applications may obtain different exi streams and any
hipotetical signing of such streams would not allow interoperability.

3. Finally, I have also noted that no mention is made to the management
of special attributes in the xml namespace (xml:base, xml:lang). Some of
them affect not only to the element where they appear but to its
children, which, for the XML Signature processing, may have strong
implications if, for instance, a transformation leaves out of the "to be
signed" fragment the element where these attributes appear, but not its
children....

2 and 3 are related with the issue of obtaining a canonical
representation of a XML document / fragment which first includes those
xml namespace attributes that affect the elements present in the
to-be-signed document / fragment and second ensures that the same
sequence of bytes are managed by two different applications. After
reading the exi draft I am not sure that exi spec provides by itself
these two features....

Best regards

Juan Carlos Cruellas.

Received on Monday, 5 May 2008 18:48:43 UTC