W3C home > Mailing lists > Public > public-xmlsec-maintwg@w3.org > April 2008

Comments and questions on EXI and its implications regarding XML signature

From: Juan Carlos Cruellas <cruellas@ac.upc.edu>
Date: Mon, 14 Apr 2008 10:26:41 +0200
Message-ID: <48031541.2040308@ac.upc.edu>
To: public-exi@w3.org, XMLSec <public-xmlsec-maintwg@w3.org>, Juan Carlos Cruellas <cruellas@ac.upc.edu>

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, 14 April 2008 08:27:24 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 14 April 2008 08:27:24 GMT