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

Anders Rundgren <> Tue, 30 April 2019 06:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 74AF1120171 for <>; Mon, 29 Apr 2019 23:39:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.998
X-Spam-Status: No, score=-0.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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ypXo7jQAZcTX for <>; Mon, 29 Apr 2019 23:39:15 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::435]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 043DB120098 for <>; Mon, 29 Apr 2019 23:39:14 -0700 (PDT)
Received: by with SMTP id c5so19551106wrs.11 for <>; Mon, 29 Apr 2019 23:39:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=wvAZlLsdfzewNCjkafRzY9dE8nAyjVKfTntL2FhJ+HI=; b=pQU75udzC0ODo2OOaVEKop0PYOGDjeJNNzcGde06Rd4egjUd+P9bXqVvqzVSEsO4Pq 2UNfin+sq4DuEXfPIPPqBmMMSm9nE3PTfpHFhJOwM/1mHpe828CGJWjDS0KytJDVWZGS 4eunOdz9RkbzWCbWA2drUhv8SzGo5Fiu9meaUS0JeOTpwfxjdlEiGTxrQDrneR+Ql+zF V22PpS0VxDqP6x5us84zNRjgbNWCs3wAciW7oYU2q1JNaGq+q7CIs54oAl4Gr7ihi0RO KvuaNCcbsvE4HmgX0KZITloeeUocSECXwKIAn+r+QnbJSK3Ke6UVQ5NHsGOOHQzJl+H3 2f/A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=wvAZlLsdfzewNCjkafRzY9dE8nAyjVKfTntL2FhJ+HI=; b=hb83xiBVaYEULzEcZSE57AicgmOED6AP2m9Ei3g94/oe/sO5xm74RVk9gDsX6pYjUp GGExnHUEE0CRKPINXOcXjf19dZ9/d5L9WTJ9qckOBgKAV9nx0e2RZgMRJAQzwsQDuJre o+JtPnqlO5QtIqWLEgZtanxPMHhQvJOrRYKBs/YFuwiQxYqsew4YG6sxj9pckZS+CJun ElbxWrNcb3NOawKoXkaycCUdLkv/1PHKsX80kiuKj8ZY93NeKUSoy/tsMFiIoiCmyzNP 6YN8eN0XKFnrLNqeesJzXyTYINljoB+LEaGtr/P11cX4bqa//CPTqgjcnxPtZv4d+WKQ TQpQ==
X-Gm-Message-State: APjAAAVBAp2KKSWTIzGv+IBtDNBRf5zY0QbSgAP/uYl2njkaLSrFFaB4 DeVpesmZYoOxHm69dSjhSWg=
X-Google-Smtp-Source: APXvYqxtKJIgX+CHh2cZrPpipxoNlBvZDfDLXpcmTrx8w5wd4i9HGTbWWS7aawPOq7oFhzDHEI52zA==
X-Received: by 2002:adf:c6c3:: with SMTP id c3mr1785410wrh.267.1556606353451; Mon, 29 Apr 2019 23:39:13 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id s124sm1431175wmf.42.2019. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 29 Apr 2019 23:39:12 -0700 (PDT)
To: Brian Rosen <>, Bret Jordan <>
References: <> <>
From: Anders Rundgren <>
Message-ID: <>
Date: Tue, 30 Apr 2019 08:39:09 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------079594233528F3B6B4AB7685"
Content-Language: en-US
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 06:39:17 -0000

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:


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" 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