AW: Canonical EXI application

Hi Frederick,
Thank you very much for your comments and apologize for the delay in responding.
We will consider your points carefully and will try to keep you informed when making progress. That said, if you or anyone else has additional comments please do not hesitate to get back to us.
Thanks,
-- Daniel

_____________________

Von: Frederick.Hirsch@nokia.com [Frederick.Hirsch@nokia.com]
Gesendet: Mittwoch, 5. Februar 2014 18:37
An: Peintner, Daniel (ext)
Cc: Frederick.Hirsch@nokia.com; public-xmlsec@w3.org; public-exi@w3.org; edsimon@xmlsec.com
Betreff: Re: Canonical EXI application


Daniel

I have put comments inline.

regards, Frederick

Frederick Hirsch
Nokia



On Feb 5, 2014, at 4:17 AM, ext Peintner, Daniel (ext) <daniel.peintner.ext@siemens.com> wrote:

> Dear XML security experts and EXI fellows,
> 
> As you may have noticed the EXI working group recently published the first public working draft for "Canonical EXI" [1] and is currently working on the second version.
> 

> Canonical EXI is meant to offer the same properties as Canonical XML and allows comparisons of XML documents where plain-text XML is difficult to handle due to various reasons (e.g., document size and processing overhead).
> 
> One prominent application field for Canonical EXI is XML signature. During signature generation, the digest is computed over the canonical EXI form. The canonicalization process of EXI bases upon the knowledge of the used EXI options [2] which is an optional part of the EXI header. These options communicate the various EXI options that have been used to encode the actual XML information with EXI.
> 
> Hence, the EXI options are crucial to be known (e.g., out-of-band if not present in the EXI stream) by the recipient to successfully validate the signature.  We see two independent layers.
> 
> 1) What gets hashed
> We would tend to recommend that the hash is generated for the Canonical EXI stream taking also into account EXI options.

It seems appropriate to protect the information about the options by including them in the signature calculation.

> 
> One issue in that regard is the schemaId in EXI.  The EXI specification does not dictate the syntax or semantics of this field. Hence we assume that applications take care of the appropriate use.


You know what happens when one “assumes”. If this cannot be specified then a warning should be included as to risks.

> 
> 2) How to exchange and share the EXI options within XML Signature
> Based on feedback and internal discussions the question arises whether and how the EXI working group may facilitate sharing te EXI options.
> 
> We have been identifying possible approaches (exclusively a, exclusively b, or permit both a and b).
> 
> a) EXI options within XML signature
> The EXI options shall be exchanged within XML signature (for example as values within the <CanonicalizationMethod> element).

I’m not sure, perhaps Signature Properties? http://www.w3.org/TR/2013/REC-xmldsig-core1-20130411/#sec-SignatureProperties

> 
> b) EXI options within EXI canonicalization The EXI options ought to be a mandatory part of the EXI stream.
> 

This could be reasonable depending on EXI implications - does  EXI WG have a viewpoint on these choices? 

> 
> Depending on the point of view (e.g., security vs. complexity) we can see various pros and cons and would like to get your feedback on our reasoning.

EXI options should be protected in the signature, seems simpler to make explicit in signature calculation, choice a, unless other reasons to adopt b (I do not know the details well enough to know)


> Also we are keen to know whether you think the work should be handled within the EXI specification and/or the XML signature work.
> 

I believe new work should continue in the EXI WG as the XML Security WG is not active right now, having completed its 1.1 deliverables.

> Thank you very much for any insight,

Others on this list might have suggestions as well.

You might also consider what would help or harm adoption by implementers and maybe seek their feedback.

> 
> Daniel
> for the EXI Working Group
> 
> [1] http://www.w3.org/TR/2013/WD-exi-c14n-20130924/
> [2] http://www.w3.org/TR/exi/#options

Received on Wednesday, 19 February 2014 15:59:14 UTC