Re: AW: Additional Canonical EXI comment

Daniel

thanks, comments inline 

thanks for your reply

regards, Frederick

Frederick Hirsch
Nokia



On Oct 17, 2013, at 4:28 AM, ext Peintner, Daniel (ext) wrote:

> Hi Frederick,
> 
> Thank you very much for your detailed review.
> Please find inline our response to your comments (1) and (3).
> 
>> (1) How are the choice of EXI Options and Schema Options
>> recorded with the canonical form - so for example, it can be
>> archived and the signature verified at a later time?
>> 
>> Perhaps this should be defined as part of the Canonical EXI
>> specification, to make explicit the options that matter to
>> canonicalization and how they are recorded with the canonical form.
>> 
>> If only known out of band this could severely limit the use cases
>> for which signatures would be useful.
> 
> Let me first try sketch the idea behind Canonical EXI.  We believe that Canonical EXI should provide a mean that guarantees having the "same" EXI Document with different flavors to produce the same octet stream. We do not plan nor intend to create a new signature and/or encryption framework. That said we primarily focus on eliminating flexibilities that the EXI format itself offers to guarantee one pre-defined way of representing the same set of information.
> 
> An EXI stream may or may not contain the EXI options that were used to encode the stream. The only assumption Canonical EXI makes is that when the signature (the hash value) is build only the EXI body stream must be used (no EXI options). This is done so to allow both scenarios (EXI options as part of the EXI stream or without EXI options) without breaking the signature hash value between both scenarios.
> 
> The exchange of EXI options that are relevant to properly process the EXI stream is up to the use-case. There might be use-cases where the EXI options are exchanged out-of-band or are known or maybe also set somehow. Other use-case may require to exchange the EXI options as part of the EXI stream itself.


this makes sense. I suggest you add the last two paragraphs of your response ("An EXI stream... stream itself." ) to the document introduction.

> 
>> (3) It might be helpful in section 3.2 to indicate how the
>> recipient distinguishes the ds:Signature element (containing
>> signature value and algorithm/hash information) from the EXI
>> stream and thus excludes it from the calculation.
>> 
>> Presumably this is done via the ds:Reference in the signature
>> referring to the enclosing EXI document and thus acting as an
>> enveloped signature, though a detached signature should also
>> be possible.
> 
> It is very good to have your view on that issue since you are the expert in that area. Our assumption is that Canonical EXI is just a mean to create a canonical form. The use of these capability is completely up to the application. For example the signature framework must handle whether an enveloped or a detached signature is used.
> 
> Do you think what we provide is not sufficient and you expect the working group to go further. 

The reason I raised this comment is that section 3 'Canonical EXI Applications' purports to discuss the use of Canonical EXI in the context of use, thus moving beyond
merely describing the canonicalization process.

I believe having this section is useful and appropriate.

I think it might be enough to add a sentence at the end of section 3.2 along the lines of

"In the case of XML Signature processing, a detached signature can be used or an enveloped signature, in which case the signature element is not included in the hash calculation."

(Of course this may not be what the EXI WG has in mind, but I'm assuming it is the implicit assumption).


> 
> Thank you once again for all your comments,
> 
> -- Daniel

Received on Thursday, 17 October 2013 18:56:29 UTC