- From: Juan Carlos Cruellas <cruellas@ac.upc.edu>
- Date: Mon, 14 Apr 2008 10:26:41 +0200
- 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 UTC