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

Bret Jordan <> Wed, 28 April 2021 15:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6AC6A3A1039; Wed, 28 Apr 2021 08:25:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 YOUogliFKVKy; Wed, 28 Apr 2021 08:25:54 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::631]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D749B3A1038; Wed, 28 Apr 2021 08:25:53 -0700 (PDT)
Received: by with SMTP id a11so2141209plh.3; Wed, 28 Apr 2021 08:25:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=AVHEfjnyShwhifQC19SJL37TN7cqfpKhSN8OC+9S0c0=; b=g3smjzvzpFt4TeZx6km/AaWTl9r4XP7+54x7aAO2n6yuXRrsiX5OuQctji87JXWbx2 r3lrd5ghAUMmV89Rfyk3bEiKo/hyoB+rLF2FtZV2UepmFL556DRD1Ra+7s3W0a+Iu6Wi qtylrI6MLju4xdUuWesGERGj4zlmClxZc+cfWH8Xqe2pn/5IxyBpeXDLm7lpuRL2AgU+ 0Qhj8aUnptRyRjW6JC/JtG0W6HTwMqna7LpY/WpOK/Lhj9qNlcfzm9TbIrTNbhgluofs d7RBWfGGtRkR4s0/VknA7Tw4j4rFqfVNmZIB/RvwtwulwcT09cwjaQsZ8RtFL80HahcS CiZw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=AVHEfjnyShwhifQC19SJL37TN7cqfpKhSN8OC+9S0c0=; b=j7lI8RumG6mMREC3zergZxjBIVjdLlktzqAHeYx4zhXO7GeKaGbiKtG6lSByxN1dNa qhg9gUaeVv5C5ixCwEdaxq0tJd7M5/ZMXA5KHcrR/1FmzzKtQSEP6vcV9I0z73Q7r8HS HnPDWWukBZ05+rTDymNoMWzdbCHjgfJwpCOn/M2EYsU6a+yRKCUuPW3u//W2UQsOCnH7 xIo/kkI/IJk60fHA2GbNG30OzEiP/uWTsssINYgtaaSGyRniwWyIdx99VLKkxLLTot9N ulLg5gk9ryARkCnq0ZvlA6SpJOgGJszzitu7tS0RXS6NtmF23N6FxA8aWDZqY9xfKgDW QCYg==
X-Gm-Message-State: AOAM532OqtQoVbyl5NvAtcET6Jp0fa4NEzi5TqOq+xlUmMFZbFbTJJvy EAQvVOy893Juj1o3tYns7W8=
X-Google-Smtp-Source: ABdhPJxceEm7FwyHlLcx1sQh8EMqmy2ZXfExzWRmSxyuo2MBYIdSH56HrQYLJwR0B3gkn/lC+QoABg==
X-Received: by 2002:a17:90a:b78d:: with SMTP id m13mr4756774pjr.47.1619623550750; Wed, 28 Apr 2021 08:25:50 -0700 (PDT)
Received: from ([]) by with ESMTPSA id s21sm5220071pjr.52.2021. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 28 Apr 2021 08:25:49 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.\))
From: Bret Jordan <>
In-Reply-To: <>
Date: Wed, 28 Apr 2021 09:25:46 -0600
Cc: Anders Rundgren <>,, DISPATCH <>,, IETF SecDispatch <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <>
To: Stefan Santesson <>
X-Mailer: Apple Mail (2.3654.
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: Wed, 28 Apr 2021 15:25:59 -0000

Hi Stefan,

Here is one of many use cases. Imagine a connected graph of threat intelligence data that is all represented in JSON. This data is processed, searched, analyzed, and forwarded between N number of entities. Some of the nodes in this connected graph are very large, 100 of MB to GB. Now entities 1…N  desire to sign both the nodes and the edge of this graph and issue them out to the ecosystem to increase trust and verification of the data in the graph. Entities need to be able create and issue detached signatures for data in the graph that they do not own but that they know is correct and valid. Further, a consumer of the data may need to process the signatures independently of the data in the graph. 

This is but one of many use cases where traditional JWS <header>.<b64 data>.<signature> does not work. 


> On Apr 28, 2021, at 3:29 AM, Stefan Santesson <> wrote:
> RFC 7797 is supported by common open source such as Nimbus and I use it
> for instances where you obviously do not need a URL safe token.
> As such it works for JWS but Not for JWT. But It works really well and
> saves space when URL safeness is not needed.
> So I guess your answer is that it still encapsulates the signed JSON in
> the signature, and that the proposal really is about embedding signature
> in the JSON object being signed (and not about whether the JSON is in
> plaintext).
> Could you elaborate why you think it is important to NOT embed signed
> data in the signature?
> What is the usecase?
> /Stefan
> On 2021-04-28 11:00, Anders Rundgren wrote:
>> On 2021-04-28 8:52, Stefan Santesson wrote:
>>> How is this different/better than implementing RFC 7797 and apply the
>>> header b64=false in order to carry plaintext JSON in the payload?
>> Good question!
>> Apart from the fact that the data becomes embedded in the JWS
>> signature container (=changing the structure), you cannot really put
>> JSON there:
>> My guess that the only real-world use of this option is to save an
>> internal-only (but technically redundant) Base64Url-operation for
>> truly detached data, be it it JSON, PNG, etc.
>> JWS/CT was designed for signing JSON Objects ({}), and let them remain
>> as such.
>> Thanx,
>> Anders
>>> /Stefan
>>> On 2021-04-28 04:29, Bret Jordan wrote:
>>>> Luckily this time we have RFC8785 that solves the canonicalization
>>>> problem for JSON.
>>>> Bret
>>>> Sent from my Commodore 64
>>>> PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050
>>>>> On Apr 27, 2021, at 7:39 PM, Dick Hardt <> wrote:
>>>>> I am supportive of this work, and would also be willing to work
>>>>> towards a PS. I am seeing rapid growth in the demand to embed JWS
>>>>> in JWS.
>>>>> Given my experience with XML-DSig (see below) making it more
>>>>> XML-DSig like does not sound like a good thing.
>>>>> For any interested in some JWT history, when we were brewing up
>>>>> what became OAuth 2.0, we did not want to tie a token format to the
>>>>> implementation as many deployments had their own proprietary token
>>>>> formats -- but we knew new deployments would benefit from
>>>>> standardizing a token.
>>>>> Our requirements were:
>>>>> - URL safe (access tokens at the time were often passed as a query
>>>>> parameter -- I know, not the best idea, but working with what
>>>>> people wanted)
>>>>> - HTTP header safe
>>>>> - richer than name / value pairs
>>>>> Options we considered:
>>>>> ASN.1 - the 60s are calling and want their data back
>>>>> XML-DSig - not URL safe, large size, and I personally had many
>>>>> scars canonicalizing XML. (An earlier company of mine had a
>>>>> contract to build XML-DSig libraries for a few languages)
>>>>> JSON was becoming very cool at that time, and with base 64 URL safe
>>>>> encoding the string, it was URL safe, and treating the JSON text as
>>>>> binary dealt with the canonicalization concerns -- and JSON
>>>>> canonicalization did not exist.
>>>>> Using a dot as the separator between header, payload, and
>>>>> signature made it easy to parse. The dot was URL safe, but not in
>>>>> the base 64 set.
>>>>> And Simple Web Tokens were born -- to be renamed JSON Web Tokens.
>>>>> /Dick
>>>>> ᐧ
>>>>> On Tue, Apr 27, 2021 at 8:28 AM Bret Jordan <>
>>>>> wrote:
>>>>>     Dear Dispatch,
>>>>>     Anders Rundgren, Samuel, Erdtman, and I have been working on
>>>>> an ID for your consideration. This document describes how to use
>>>>> JWS and JCS to create plain-text JSON signatures. The abstract
>>>>> reads as follows:
>>>>>     This document describes a method for extending the scope of
>>>>> the JSON Web Signature (JWS) standard, called JWS/CT.  By
>>>>> combining the detached mode of JWS with the JSON Canonicalization
>>>>> Scheme (JCS), JWS/CT enables JSON objects to remain in the JSON
>>>>> format after being signed (aka "Clear Text" signing).  In addition
>>>>> to supporting a consistent data format, this arrangement also
>>>>> simplifies documentation, debugging, and logging.  The ability to
>>>>> embed signed JSON objects in other JSON objects, makes the use of
>>>>> counter-signatures straightforward.
>>>>>     The data tracker page for this:
>>>>>     As you know there are large ecosystems that needs digital
>>>>> signatures for plain text JSON data, meaning where the JSON data is
>>>>> not base64 encoded. This ID provides a solution using existing IETF
>>>>> RFCs to make this work. Further, this work looks to be adopted by
>>>>> many groups and organizations from financial services, threat
>>>>> intelligence, and incident response.
>>>>>     We are not sure what direction would be best for this work
>>>>> in the IETF, should we send to the ISE for publication or do you
>>>>> want to create a working group. Ultimately there is a lot of work
>>>>> that could be done in this space to meet the needs of the market.
>>>>> We would be happy with releasing these IDs for ISE publication, or
>>>>> for creating a working group to move them forward. It is just
>>>>> important to note that the market is in desperate need of these
>>>>> solutions. If you want to take it for a spin, there is a JWS/CT
>>>>> playground at:
>>>>>     Thanks
>>>>>     Bret
>>>>>     --
>>>>>     Sent from my TI-99/4A
>>>>>     PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8
>>>>> ACAE 7415 0050
>>>>>     _______________________________________________
>>>>>     art mailing list
>>>> _______________________________________________
>>>> Secdispatch mailing list
>>> _______________________________________________
>>> dispatch mailing list
>> _______________________________________________
>> Secdispatch mailing list
> _______________________________________________
> dispatch mailing list