Re: [jose] Canonical JSON form

[Anders Rundgren <[e-mail]>]

Dear David et al,
I believe we all know IETF's position on this topic by now.

Anyway, there is considerable interest maintaining the core quality of text based messages (human readability) also for signed data, leading to various quests for alternative solutions.

To give some kind of perspective on the complexity, my C#/.NET implementation [1] weighs in at 30 Kb of executable code.

It took 3 complete revisions and five calendar years to get to this point but it was (hopefully) worth it :-)

Thanks,
Anders
1] https://github.com/cyberphone/json-canonicalization/tree/master/dotnet

On 2018-10-22 04:47, David Waite wrote:
> 
> 
>> On Oct 19, 2018, at 10:55 PM, Anders Rundgren <[e-mail] <mailto:[e-mail]>> wrote:
>>
>> There is also a (very active) W3C community group working with a similar concept so clear-text signatures based on JSON canonicalization will probably reach the market regardless of IETF's position on the matter: https://w3c-dvcg.github.io/ld-signatures/
>>
> 
> This document is not on a standards track. The group which published this it is not a standards group. So this isn’t currently on track to reach the market as a IETF or W3 standard.
> 
> It also is based on RDF canonicalization; it canonicalized a specific format expressed in JSON, not arbitrary JSON.
> 
> That isn't to say that there couldn’t be multiple canonicalization formats supported, possibly built as filters so you could combine them together, such as existed with XML-DSIG. Then you have a compatibility matrix to deal with.
> 
> This still doesn’t solve the problem that many internal representations of JSON will not preserve the full data set you are representing in your canonical form.
> 
>  From my development experience with XML-DSIG, this is most commonly that tools will discard information they do not understand, such as properties which aren’t part of the public schema. For developers who do not understand the additional restrictions a cleartext signature is placing on them, this causes issues that only come up late in broad interoperability testing, that can only be resolved through per-vendor workarounds or reimplementation to use different tools. This actually occurred multiple times across different implementations, sometimes when leveraging libraries that did claim to preserve the full information set of the XML document.
> 
>> The 1 million of random and "edge" JSON Numbers used for testing the devised JSON canonicalization scheme, uncovered flaws in other systems as well...
>> https://github.com/dotnet/coreclr/issues/17467
> 
> This yet another case against canonical JSON, is it not? Or rather, how are people expected to deal with intermittent interoperability failures until a new language runtime release which revises the numerical print and parse functions comes out?
> 
> -DW