Re: [jose] Canonical JSON form

Oh there is real need.  Several standards and implementations inside the IETF and outside the IETF in other SDOs need this.  So in my view there are a few options:

1) Try and convince a working group here in the IETF that this is a good idea so we can actually work on it. 

2) Work on this in another SDO outside the IETF (ETSI, OASIS, ITU, etc etc etc)

3) Do this work as an industry standard similar to what happened between W3C and WHATWG. 

I would personally prefer that this work be done here in the IETF.  But there seems to be a lot of resistance here. I am willing to work on this and help make this a reality.  There is a lot of great prior work on this.  

Maybe we can have a meeting in Prague?  Or I can setup a Telepresence WebEx after Bangkok and all those that are interested can join and we can discuss next steps. 

Thanks,
Bret
PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg."

> On Oct 28, 2018, at 2:32 PM, Samuel Erdtman <samuel@erdtman.se> wrote:
> 
> In my opinion we can create a good canonicalization format for JSON to be used to sign cleartext JSON.
> 
> As can be seen on this list many are skeptical so my approach would be to publish easy to use open source implementations. If we do that and there is real interest then we might be able to convince people here about the need. In line with this ambition I have done the JS and Java publications. This might also show there is no actual interest and then that is also an outcome.
> 
> Best regards
> //Samuel
> 
> 
> On Mon, Oct 22, 2018 at 8:44 AM Carsten Bormann <cabo@tzi.org <mailto:cabo@tzi.org>> wrote:
> On Oct 22, 2018, at 04:47, David Waite <david@alkaline-solutions.com <mailto:david@alkaline-solutions.com>> wrote:
> > 
> > intermittent interoperability failures until a new language runtime release which revises the numerical print and parse functions
> 
> Note that this is not a theoretical concern, as CVE-2010-4476 and CVE-2010-4645 amply demonstrate, nicely underscored by the re-occurrence of the latter in https://www.exploringbinary.com/php-converts-2-2250738585072012e-308-incorrectly/ <https://www.exploringbinary.com/php-converts-2-2250738585072012e-308-incorrectly/>
> 
> Grüße, Carsten
> 
> _______________________________________________
> jose mailing list
> jose@ietf.org <mailto:jose@ietf.org>
> https://www.ietf.org/mailman/listinfo/jose <https://www.ietf.org/mailman/listinfo/jose>