RE: Comments: Canonical EXI -- Last Call Working Draft

Hi John,

There was a bit similar discussions within the WG, in response to your initial comment.

I have a question regarding how you expect the receiver to know whether the digest
of the signature was originally computed with or without EXI options (or further with or
without schemaId). Knowing this is important when there are intermediary nodes that
might change EXI options settings or in some cases removes EXI options altogether
from the header before the message ultimately reaches the end node.

Thank you,

Takuki Kamiya
Fujitsu Laboratories of America



From: John Schneider [mailto:jcs@agiledelta.com]
Sent: Monday, October 05, 2015 11:15 AM
To: FABLET Youenn
Cc: public-exi-comments@w3.org
Subject: Re: Comments: Canonical EXI -- Last Call Working Draft

Youenn,

All EXI users, with or without canonical EXI, must have a way to ensure the same EXI options and schemas are used for encoding and decoding or  signing and validation. *One* way to increase certainty that this is the case is to embed the EXI options and a schema ID in every canonical EXI stream. However, this is not the only way or even the best way. So, I think its fine to identify and even recommend this practice, but we should not make it a requirement. When we’re focused on the EXI format and we see an issue that must be addressed, its easy to think the issue MUST be addressed within EXI itself (you know — when all I have is a hammer, everything looks like a nail). However, EXI generally fits within a broader architecture and sometimes the best place to address a particular issue (such as schema identity verification) is outside the EXI format. This is the reason we designed the EXI format to provide the flexibility it does. It defines simple solutions (like the schemaID) for use cases where these suffice, but allows for more sophisticated approaches when they are required.

Regarding your initial question, the specification would prevent our users from retaining their current levels of efficiency. To implement the current specification, they either have to significantly increase the size of their messages (by adding the EXI header with schema ID where it is not currently required) or they have to write additional code to separately generate, transmit, process and/or splice canonical EXI headers that are not currently required. The additional code, complexity and/or transmitted bits would only be required to meet the specification. They would not increase security or provide any functionality that isn’t already provided more effectively by their current architecture.

Again, I agree with the need to ensure the same EXI options and schemas are used by the signer and validator. Including these in the EXI stream is one way increase certainty that this is the case, but not the only way or the best way.

           Cheers,

           John


On Oct 5, 2015, at 10:12 AM, FABLET Youenn <Youenn.Fablet@crf.canon.fr<mailto:Youenn.Fablet@crf.canon.fr>> wrote:

I am wondering what exactly the specification is preventing your users from doing.

From what I understand, your users will be happy just sending EXI headers + canonical EXI bodies.
The spec allows this (and is mostly about defining that actually), which is good to me.
If one wants a name for that practice, one can for instance use “EXI stream with a canonical EXI body”.

The specification also defines another thing which adds one more constraint to the EXI stream (namely that the header is also canonical). The specification is giving it the name “Canonical EXI stream”.

One reason IIRC of adding this notion is that the working group thought that, in general, it is good practice for the signature validation to also validate the complete set of EXI options, including the schema ID.

                Y

From: John Schneider [mailto:jcs@agiledelta.com]
Sent: vendredi 2 octobre 2015 20:06
To: public-exi-comments@w3.org<mailto:public-exi-comments@w3.org>
Subject: Re: Comments: Canonical EXI -- Last Call Working Draft

Youenn,

Thank you for your suggestion. Please forgive my candor, but that sounds like a real hack to me. I would only resort to cutting and pasting headers onto EXI documents as a last resort if I had no other option. And in cases where we dynamically change EXI options based on input messages or other conditions, matching the right Canonical EXI headers with the right Canonical EXI bodies would significantly raise complexity and require repeated transmissions of Canonical EXI headers (that ultimately aren’t even needed). We have not yet poured the concrete over the EXI Canonicalization specification, so lets try to get it right and not plan to make people with legitimate use cases hack around its limitations.

Second, the users I’m talking about already have more sophisticated, more efficient and more secure ways of ensuring the same EXI options and schemas were used. They do not need the EXI header at all and any effort required to create and/or transmit and/or process it is wasted effort. That’s the penalty.

The solution to the problem is simple. Let’s retain the existing flexibility of the EXI format by keeping the options document optional. Don’t force a single solution on everyone. This will satisfy all the requirements of those that need the EXI options document and those that don’t. It will allow everyone to implement the strength of security they need for their use case, including those that need stronger security than that provided by including the EXI options and schema ID in the header.

          Cheers,

          John

On Oct 2, 2015, at 1:35 AM, FABLET Youenn <Youenn.Fablet@crf.canon.fr<mailto:Youenn.Fablet@crf.canon.fr>> wrote:

Hi John, all,

I do not really see where is the penalty.
It seems reasonable for your users to send a EXI stream that would contain whatever EXI header they like AND a Canonical EXI body.
Generation of the Canonical EXI document (only meaningful at validation time in that case) would be done by doing binary concatenation of the canonical EXI header (transmitted out-of-band) and the received EXI body.
                y

That said, there is no "on-the-wire" penalty and the added processing cost is really limited.

That is not correct. There can be a significant on-the-wire penalty for those that want the efficiencies associated with using Canonical EXI as their wire format. This is an important use case we should support without unnecessary performance penalties.

AgileDelta, Inc.
john.schneider@agiledelta.com<mailto:john.schneider@agiledelta.com>
http://www.agiledelta.com<http://www.agiledelta.com/>

AgileDelta, Inc.
john.schneider@agiledelta.com<mailto:john.schneider@agiledelta.com>
http://www.agiledelta.com

w: 425-644-7122
m: 425-503-3403
f: 425-644-7126