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

Bret Jordan <> Tue, 30 April 2019 14:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 78A8512011A for <>; Tue, 30 Apr 2019 07:42:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id jRDMvCcXgEAK for <>; Tue, 30 Apr 2019 07:42:52 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::d35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 602A8120114 for <>; Tue, 30 Apr 2019 07:42:52 -0700 (PDT)
Received: by with SMTP id h26so12447594ioj.1 for <>; Tue, 30 Apr 2019 07:42:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=51TI/ZkLTbi91Catuvbu2o/o+i5RuwurofAZMSf0vqY=; b=X07PJCIltpNgrwrYL3zKnEgQlU5nGfVaUUYxxsXYqM8QP867fg/7+ec8svjpoQPfC3 UJeDUEkNE7kWaf1zburCmJHDIuRwzf93ccMmSKgw97twdABkF7/lBWW+6N7X4XaAH4o9 K5HZYyurlC3fengHl4OHYohp8mS03pYnPhmzvVX2xZYYLTldV35mYmjBoSWAQbdmV3QT 2WLh83nJ61gEL+FWDkRgvQZhejxYUJqQTMbhqMwab4hj+NCZJ+AE0u6lliqF5ZpHm0UY 5Ym8SbzUcRM9H8kZgtf+vXtC4mzO1zRsHyKU8a+Mam39HFdNYIY5paVayv5pONgeWIS1 XQ8Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=51TI/ZkLTbi91Catuvbu2o/o+i5RuwurofAZMSf0vqY=; b=tF6Q+qsbgqf/c8FAzJstTjyZniW0JjE43vsJONb8DlGvsGqQyxXPt5tPoyYQ1B00gP iiYwdPZhlQMSxN73pCxwdjXBCB7qmFzgXto0ECMPdqviov9gru1Tq3MsMRArmUkKSy28 /Onvp7hKq6pDsTdboUGL0huLu1YYpUFphqC0xd3Mn5lBQzJw2eKiT6LDv67c4w4nKX5C aD2cGDd+5O9egq5blBnU4lFxFGpJlT1m6nxGdOci2e7tYgjRufn+OCp3Rksu9ltvDslx kn76N0+49slSaPpxmmHy47lQRVE3fovMwPxAPtRGQEgZJCOFptzF2KDxNUV2a7Uv/A1a ctBA==
X-Gm-Message-State: APjAAAVeh0UbSlwpnsPATGHh3KYmBc81oppWZ2Tspo+MeIvKhxdjwQps FJ5lYUgSxKv0KsUM7QautVk=
X-Google-Smtp-Source: APXvYqxhfK2KeifFsiYXjjSog8QQvsGhTMclmXUPDC7iAQG/undYB+xw6uhaVy2iYBghE/M01qcZsA==
X-Received: by 2002:a5d:898a:: with SMTP id m10mr43221177iol.296.1556635369513; Tue, 30 Apr 2019 07:42:49 -0700 (PDT)
Received: from ?IPv6:2605:a601:a990:4d00:68cf:8cf2:5c20:c8a8? ([2605:a601:a990:4d00:68cf:8cf2:5c20:c8a8]) by with ESMTPSA id n4sm12962695ioh.52.2019. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 30 Apr 2019 07:42:48 -0700 (PDT)
From: Bret Jordan <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_A1266082-5883-440E-B23C-66B94493496E"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\))
Date: Tue, 30 Apr 2019 08:42:45 -0600
In-Reply-To: <>
Cc: Brian Rosen <>,
To: Anders Rundgren <>
References: <> <> <>
X-Mailer: Apple Mail (2.3445.104.8)
Archived-At: <>
Subject: Re: [dispatch] JSON Canonicalization Scheme (JCS) Proposal
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DISPATCH Working Group Mail List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 30 Apr 2019 14:42:56 -0000

Yes Anders.  There is a lot of need to keep the jSON as JSON and still have signatures and even have nested signatures.  The data needs to stay as JSON so that it can be actioned on and addressed in a graph.  I am really excited about this work moving forward. 

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 Apr 30, 2019, at 12:39 AM, Anders Rundgren <> wrote:
> 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:
> <>
>      "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: <>
> 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 < <>> 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: <>
>>> Further, many successful implementations for several different platforms as well as a public "playground" <>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
>>> <>
>>> <>
>> _______________________________________________
>> dispatch mailing list
>> <>
>> <>