- From: Peintner, Daniel (ext) <daniel.peintner.ext@siemens.com>
- Date: Thu, 17 Oct 2013 08:28:22 +0000
- To: "Frederick.Hirsch@nokia.com" <Frederick.Hirsch@nokia.com>, "public-exi@w3.org" <public-exi@w3.org>
- CC: "public-xmlsec@w3.org" <public-xmlsec@w3.org>
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. > (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. Thank you once again for all your comments, -- Daniel
Received on Thursday, 17 October 2013 08:28:50 UTC