Re: [Json] RFC 8785 - JSON Canonicalization Scheme

[Anders Rundgren <[e-mail]>]

On 2020-07-06 03:10, Ulysse Carion wrote:
> Hi Anders,
Hi Ulysse,
> 
> Nice job with JCS. I've taken a stab at implementing it here (in
> Golang), because I have a possible use for something like this, and
> your Golang reference implementation wasn't super usable as-is:
> 
> https://github.com/ucarion/jcs

Great job! Your code (modulo comments) weighed in at a mere 200 lines.

> Overall, I think this document makes sense, and -- given its
> prerequisites -- is the design any one of us would have landed on
> given time to meditate on the details. 

Well, we didn't exactly "landed" there; RFC 8785 represents a third
and complete rewrite. Although working, the previous attempts were
pretty much c**p from an implementation point-of-view.  Without the
great (but sometimes rather dismissive) input from the IETF community,
it would maybe never even had happened :)


> I usually specifically avoid
> embedding signatures within the data being signed, but when that's not
> an option JCS seems a quite reasonable choice.

In my case the ability to (in a reasonable manner), serialize a signed
HTTP request was *one* of the biggest motivations.  AFAICT, none of the
current efforts in the IETF, the W3C or more recently in ETSI, have this
capability.


> Two notes on what you could do to help future implementers:
> 
> 1. I wish you could provide some sort of script that generates
> floating-point test-cases, instead of having folks download a 3.8G
> file if they want to make sure they're correctly aping JavaScript's
> float-to-string algorithm.

I'm currently spending my limited cycles on the next steps on this
journey which will take a lot of work although they are (IMO)
technically ready as well as implemented:
https://cyberphone.github.io/doc/security/jsf.html
https://cyberphone.github.io/doc/security/jef.html

> 
> 2. I don't understand why implementations MUST detect and error on
> invalid surrogate pairs. For implementations that aren't implementing
> their own JSON parser at the same time, doing so may not always be
> possible. Can you elaborate on the reasoning, and maybe offer
> implementers guidance on the relevant parts of the Unicode spec?

If you don't honor all parts of a specification, you may run into
interoperability problems.  JCS is supposed to be "complete" but
I'm sure that most people (currently including myself...), won't
bother to death about this particular requirement in their actual
implementations...


> A prospective implementer already needs to go pretty deep into the hairy
> details of floating-point numbers and character encoding, and a bit of
> guidance in the developer portal would go a long way.


There is hope:
https://github.com/ulfjack/ryu/issues/87#issuecomment-646550719

> These are just details. Overall, I think JCS is quite nicely done.
> Thanks for making this.

Thanx,
Anders

> 
> Best,
> Ulysse
> 
> 
> On Sat, Jul 4, 2020 at 11:27 AM Anders Rundgren
> <[e-mail]> wrote:
>>
>> https://www.rfc-editor.org/rfc/rfc8785
>>
>> In case you would like to test what you can do with JSON canonicalization, there are two public Web applications at your disposal:
>> Using JWS: https://mobilepki.org/jws-jcs
>> Using an "unwrapped" JWS called Java Signature Format (JSF): https://mobilepki.org/jsf-lab
>>
>> A real-world implementation from OWASP using JSF: https://cyclonedx.org/use-cases/#authenticity
>>
>> In Saturn JSF is not only a security solution, it is also used for counter-signatures to simplify state-holding in payment systems:
>> https://cyberphone.github.io/doc/saturn/hybrid-payment.html#6
>>
>> By securely embedding related messages in each other (aka "Russian doll"), there is no need for external references to previous messages.
>>
>> Enjoy!
>>
>> Anders
>>
>> _______________________________________________
>> json mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/json