Re: [Json] Canonicalization

[Francis Galiegue <[e-mail]>]

On Wed, Feb 20, 2013 at 2:39 AM, Francis Galiegue <[e-mail]> wrote:
[...]
>
> Ick. OK, well, the answer seems pretty simple: UTF-8. It is already
> recommended, I guess making is a MUST in RFC 4627bis will solve the
> issue without even the need for c14n...
>
> Nothing to lose, everything to gain.
>

Some more thoughts about this...

Signing does not require c14n at all. Signing is totally unaware of
the media type. It will sign whatever it is fed with, and does not
care about what this content actually is. So, signing, say:

----
{ "a": "b", "c": "d" }
----

will not yield the same result as signing:

----
{
    "a": "b",
    "c": "d"
}
----

and that is pretty much normal. The scope of action as far as signing
content is concerned is byte-to-byte representation. And yes, this
means that UTF-16 in these two examples will yield a different
signature than UTF-8. OK, but whatever encoding is used, it will be
_known by the receiving end_. As such, signing in itself completely
precludes the need for c14n, and as such, c14n is not needed at all
since signing is not mandatory.

What _is_ required is that interpretations on either point of a
point-to-point transaction involving JSON data interpret this data in
the same way. And as such, the more pressing matter is turning the
SHOULD NOT have duplicate member names in JSON Objects into a MUST
NOT.

But c14n is, basically, unwarranted.

At least, this is my view on the matter.
-- 
Francis Galiegue, [e-mail]
Try out your JSON Schemas: http://json-schema-validator.herokuapp.com