Re: [dispatch] [Secdispatch] [art] Plain text JSON digital signatures

Carsten Bormann <> Mon, 03 May 2021 16:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 823023A1AC3; Mon, 3 May 2021 09:06:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.918
X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id UZYqBD1MzaAi; Mon, 3 May 2021 09:06:38 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 506EE3A1ACB; Mon, 3 May 2021 09:06:33 -0700 (PDT)
Received: from [] ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 4FYnsM44y6zyY6; Mon, 3 May 2021 18:06:31 +0200 (CEST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
From: Carsten Bormann <>
In-Reply-To: <>
Date: Mon, 03 May 2021 18:06:31 +0200
Cc: DISPATCH <>,, IETF SecDispatch <>, "RFC ISE (Adrian Farrel)" <>
X-Mao-Original-Outgoing-Id: 641750791.121515-81ca36c7b085c8c48b5f85ba11209a5e
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <> <> <>
To: Samuel Erdtman <>
X-Mailer: Apple Mail (2.3608.
Archived-At: <>
Subject: Re: [dispatch] [Secdispatch] [art] Plain text JSON digital signatures
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: Mon, 03 May 2021 16:06:45 -0000

Hi Samuel,

I haven’t responded to your message yet as it triggers some MacOS mail misbehavior.
Let me try anyway, I hope you can parse the result.

> On 2021-05-01, at 23:24, Samuel Erdtman <> wrote:
>> Thanks Carsten,
>> Your clarifications were great!
>> See some comments inline.
>> On Sat, May 1, 2021 at 1:04 AM Carsten Bormann <> wrote:
>> Hi Samuel,
>> > 1. What do you mean with data at rest, data store in database or file?
>> The point is that you are not signing the data being transferred, but a local copy of some (e.g., freshly decoded) data (i.e., at the data model level) which is then processed a little (potentially taking out all signatures) and then is run through a rather complicated engine to produce a signing input that is a deterministic function of the decoded and processed data.
>> There are easier ways to get a signing input from JSON-like data at rest.
>> For a (quite workable) strawman: How about doing a CBOR encoding using deterministic encoding rules?
> This is a good point. Still not convinced other solutions would be orders of magnitude better and the proposed one is easy to implement and easy to understand (maybe too easy since I had not thought about your alternative solution). 

It is hard to measure interoperability in orders of magnitude…
Doing a CBOR signing input is easy to implement and easy to understand, though.
No UTF-16 needed :-)

>> > Or is it data that does not change? Sorry I do not get it.
>> > 
>> > 2. What is weird with saying "Represented in JSON”?
>> Your scheme does NOT require (or benefit in any way from) representing the data in JSON.
>> The data could be transferred in YAML (or CBOR for that matter): as long as your local copy of the decoded data (after the little processing) sticks inside the confines of the I-JSON data model, you can use your scheme for signing.
> But since JSON according to is fairly flexible, would not fitting it into CBOR require similar limitations as RFC8785 puts on what you can do with the JSON? (i.e. the I-JSON limitations)

It does require some thinking. documents what we arrived at when discussing that in the CBOR WG.

(I’m very well aware that many applications would be content with just I-JSON, because they already have made their peace with it to enable JavaScript classic processing.  So I’m just answering the question here.)

>> > is it that the RFC7493 I-JSON subset is not all that JSON could be? (to me this is a reasonable limitation that I in practice never have had to go outside)
>> Well, that has been debated to death, and it is clear that nobody likes I-JSON (*), but it is the de-facto boundary within which the actually more capable JSON format needs to be used these days.
>> (If you need more flexibility, you know where to find CBOR.)
> So are you saying that CBOR would not impose the same limitations on the original JSON as RFC8785? 

Yes.  Again, please see

Please note that I’m not making these points to push CBOR, even though I’m really convinced CBOR and its “JSON mode” can play a helpful role in addressing the underlying requirements.

Grüße, Carsten