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

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

regards, Frederick

Frederick Hirsch
Nokia



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  
> 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 Thursday, 25 September 2008 18:18:52 UTC