Re: [dispatch] JSON Canonicalization Scheme (JCS) Proposal

[Anders Rundgren <[e-mail]>]

Thanx Bret and Brian,

The core motive behind this scheme can in short be described as "keeping JSON as JSON, also when signed".

It turns out that even hard-core security folks like the TEEP WG (who use the current and rather intrusive JWS/Base64Url scheme), in order to maintain a reasonable message structure were forced putting every message in unsigned outer JSON "holder" objects which does not only look weird but also creates additional issues:

https://tools.ietf.org/html/draft-ietf-teep-opentrustprotocol-02

      "The top element "<name>[Signed][Request|Response]" cannot be fully
        trusted to match the content because it doesn't participate in the
        signature generation.  However, a recipient can always match it with
        the value associated with the property "payload".  It purely serves
        to provide a quick reference for reading and method invocation"

Using JCS with JWS the need for artificial holder objects and associated matching requirements disappear, while message content is provided in clear.

Although not a part of this particular effort, you can also apply JCS to the signature container itself making algorithms, public key values, etc. fully readable.  An example of such a solution can be found at: https://mobilepki.org/webpay-payeebank/payees/86344

thanx,
Anders


On 2019-04-29 21:17, Brian Rosen wrote:
> I like this work and would like it to move forward.  A use case I have is the recording system for emergency calls.  Everything is recorded and the recorded data is used real time as history of an incident, rather than retaining it both in some temporary system and in the main recording system.  That means that the recording system is frequently consulted real time as the incident progresses.  Signatures are used throughout, primarily for non-repudiation.  You only validate the signature months after the event, when lawyers want to make sure transcripts are accurate.  Having to do more work to get the data is not desirable.
>
> I will review, comment and participate actively in this effort.
>
> Brian
>
>
>> On Apr 29, 2019, at 2:44 PM, Bret Jordan <[e-mail] <mailto:[e-mail]>> wrote:
>>
>> Dispatch,
>>
>> During IETF 104 there were several meetings and sessions about the proposed JCS solution. This JCS solution defines a way to canonicalize JSON data to enable hash-able JSON. After listening to and working through most of the concerns that were raised, there seems to be some significant interest and use-cases for moving this work forward.
>>
>> We respectfully request that DISPATCH look at this work and determine where it would best fit in the IETF.  We would also like to request that DISPATCH add this to the next interim or full meeting.
>>
>> The current draft can be found here: https://tools.ietf.org/html/draft-rundgren-json-canonicalization-scheme-05
>>
>> Further, many successful implementations for several different platforms as well as a public "playground" https://mobilepki.org/jws-jcs/home have been created to show that this not only works, but is pretty easy to implement.
>>
>> Personally I know many organizations and solutions that desperately need this for production. Thank you for your consideration.
>>
>>
>> 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."
>>
>> _______________________________________________
>> dispatch mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/dispatch
>
>
> _______________________________________________
> dispatch mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dispatch