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

Carsten Bormann <> Wed, 28 April 2021 15:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 96BF13A11CD; Wed, 28 Apr 2021 08:55:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.919
X-Spam-Status: No, score=-1.919 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] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id cY3R4VIJPLw2; Wed, 28 Apr 2021 08:55:09 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 01E563A1248; Wed, 28 Apr 2021 08:55:03 -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 4FVjrN6Q8Bzyft; Wed, 28 Apr 2021 17:55:00 +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: Wed, 28 Apr 2021 17:55:00 +0200
X-Mao-Original-Outgoing-Id: 641318100.441141-a8485cd991b2d7abdf0fa7b7c59963eb
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <>
To:, IETF SecDispatch <>, DISPATCH <>,
X-Mailer: Apple Mail (2.3608.
Archived-At: <>
Subject: Re: [dispatch] [art] [Secdispatch] 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: Wed, 28 Apr 2021 15:55:12 -0000

Signing data at rest certainly is a use case that is worth addressing.

“Represented in JSON” is a weird way to say that the data model that describes those data at rest is somehow compatible with the JSON data model (which isn’t really fully defined, but that is a problem that may not hurt you).  So if you have a deterministic way to transform your data at rest into the JSON-like data model subset supported by RFC8785 (which is in turn based on the RFC7493 I-JSON subset), you then can use RFC8785 to generate a text string that (using UTF-8’s deterministic encoding) can in turn be used as a signing input for well-known signature schemes such as JOSE or COSE.

This is pretty much what XMLDSig set out to do, except that the XML data model is even less well-defined and generating a deterministic signing input from that is even more interesting.  Small matters of interoperability :-)

None of this has anything to do with “clear text” or “plain text", which is an exceedingly bad label to apply to signing data at rest that are believed to be convertable to an RFC8785-subset JSON text.

Grüße, Carsten