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

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

From: Frederick Hirsch <frederick.hirsch@nokia.com>
Date: Thu, 25 Sep 2008 14:17:45 -0400
Message-Id: <C897A2AA-259F-4066-A6E1-8DA840FF9C23@nokia.com>
To: XMLSec WG Public List <public-xmlsec@w3.org>

This may be useful for background reading regarding EXI and  
canonicalization in advance of our joint session.

regards, Frederick

Frederick Hirsch

Begin forwarded message:

> Resent-From: public-xmlsec-maintwg@w3.org
> From: "ext Taki Kamiya" <tkamiya@us.fujitsu.com>
> Date: May 5, 2008 2:13:31 PM EDT
> To: "'Juan Carlos Cruellas'" <cruellas@ac.upc.edu>, <public- 
> exi@w3.org>
> Cc: <public-xmlsec-maintwg@w3.org>
> Subject: 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  
> 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 Thursday, 25 September 2008 18:18:52 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:55:09 UTC