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

Anders Rundgren <> Sat, 01 May 2021 05:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 60CAC3A34FE; Fri, 30 Apr 2021 22:09:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Status: No, score=-2.099 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, NICE_REPLY_A=-0.001, 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 VWlxTTEL-Erj; Fri, 30 Apr 2021 22:09:55 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::42a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id ACE723A34F6; Fri, 30 Apr 2021 22:09:54 -0700 (PDT)
Received: by with SMTP id a4so86153wrr.2; Fri, 30 Apr 2021 22:09:54 -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:content-transfer-encoding; bh=u8qIHe5b4hf0eWlCnhn0XaplDlT7QB4WqvllYh2vxb8=; b=Fp8hljepo4sks3fFVW0zZOC3wnSIXMo3BkxPnwl7nMLkFVwTAIw53SooS7D2ddeVoI JaKMZezUcu28YhvHMPOG0CIn5L52tjGon5V6TZPcdnz75hY9wo4ec4NhvLCONnq10/0f N+LDdK1pGZuiQinpt0GQMkChuZvh6GoO3HVDJFo8XFBJAhOqlAK6LuPX23DIdBnfi+1Q DxDjdyLUHuvZxK+4dFP/CgWNKn0bRzg0DMVfCo3pSutJDmHKAMdweWLicqmw6lF2tbhm V29EevScth3e451Lff9PIC7Lj9Q2wHZjyiTEegjQdLQER8rNt8z24pHeigGU4wXLMJae vkpA==
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 :content-transfer-encoding; bh=u8qIHe5b4hf0eWlCnhn0XaplDlT7QB4WqvllYh2vxb8=; b=XRLMIsAncl2n6X0A5XNKMhEhWCQiBiogZK/YLm7EYDlO3ry0gnmU0KkgEYPQKgh6S6 v/cha7TZzVnmFuLfvrjjtLwy7W0ErWwb/eKCBtRSpML+jVJuyyh7G9y+GYR1etd6seHc GpRhxljBpzwxXPkdt4cwCBq1te+Kvj8IDS1bNqqCY1Npannfvuj7UdZaGL0MwMq+4sNe +A4FDhrzZY+QKRUuveG/Iv4kkjujW++YVSSBjU0uHkzd2fbo5E1/2QdLJJXmStgyHhEu NhOqy97Y45crcO2F/SeiQT1cbxl0wmkptIYvvrSlBA4plmpTJ4T3ukJxrpZcwJJx59cX h5zA==
X-Gm-Message-State: AOAM531MR/ORc9lpkbSCJDwXLPV0Vz7qgMbBZOf3hHxY6bCbO7Yks0YL XTRXdr7SWmppBW1ecIwje70=
X-Google-Smtp-Source: ABdhPJzG2Vd42Waskgx8kWUJYOI4N8KXoR7jnjvsu4mE1+ikwFDArIryXdIfrxdWSDnuL4Jz3J1LFg==
X-Received: by 2002:adf:facf:: with SMTP id a15mr12132964wrs.53.1619845791872; Fri, 30 Apr 2021 22:09:51 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id y125sm4560376wmy.34.2021. (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 30 Apr 2021 22:09:50 -0700 (PDT)
To: Carsten Bormann <>, Samuel Erdtman <>
Cc: DISPATCH <>,, IETF SecDispatch <>, "RFC ISE (Adrian Farrel)" <>
References: <> <> <> <> <> <> <> <> <>
From: Anders Rundgren <>
Message-ID: <>
Date: Sat, 01 May 2021 07:09:48 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
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: Sat, 01 May 2021 05:10:00 -0000

On 2021-05-01 1:04, Carsten Bormann wrote:

 > Your scheme does NOT require (or benefit in any way from) representing the data in JSON.

I don't have an answer or solution for people who firmly believe that JSON is (more or less) useless.

Stepping-up the game a bit :)
We have had 25y+ (!) of non-standard, security-broken, and user-hostile on-line payment-systems.  AFAIK, the following document is currently the ONLY specification that addresses this obvious deficiency:
Browsers, FIDO, JavaScript, JSON, JWS, JWE, RFC 8785, and JWS/CT are the corner stones of this proposal. Yes, there is even a spoon with CBOR/COSE there.

Regarding RFC 8785, it works as claimed for applications adhering to two fairly reasonable requirements:
- Sticking to I-JSON where the SHOULDs are interpreted as MUSTs.
- Using parser schemes that do not mess up data embedded in JSON strings (like converting "2021-05-01T10:00:00Z" to "2021-05-01T09:00:00+01:00").

In all "modesty",

> 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?
>> 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.
>> 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.)
>> 3. So I totally get that one does not like XMLDigSig, in my opinion not because of the signing procedures but because of the canonicalization process. When I looked at it I gave up and created a hardcoded template. The difference in canonicalization of JSON (RFC7493 I-JSON subset) according to RFC8785 is like night and day compared to XML canonicalization. In your comment it seems like you are of the opinion that this effort will be as tricky as XMLDigSig. do you think so?
> Indeed, the RFC 8785 encoding is (ignoring potential problems on the numeric side) simpler than canonicalized XML, even with its weird regression to UTF16-land.
> Much of the actual problems of XMLDSig weren’t in the canonicalization, but in the confusion of how the data at rest was to be processed for signing, e.g., what part of the data at rest was contributing to the signing input and what the signature on that part then actually meant.  JWS is probably flexible enough that a carefully constructed application can get all this right, but we are talking about non-trivial specifications needed beyond the boring part of generating the byte-string signing input.
>> 4. Not sure I agree with “clear text” or “plain text" being bad descriptions. Yes what is signed is the RFC8785 transformation of the input data, but the signature are then put into your data keeping the data in its original “clear text” or “plain text" as opposed to base64-url encoded. I guess enveloped JWS is a more accurate name but “clear text” or “plain text" is easy to understand.
> Well, I understand that the naming you chose is a good strategy for selling the scheme.
> It is, however, not describing what is actually going on, and I try to minimize the use of misleading terminology.
> Grüße, Carsten
> (*) Over at the JSON mailing list, there has been some fresh discussion just this week about how to get around some of the implementation limitations, or JSON’s (deliberate!) lack of extensibility, or both.  Archived-At: <> and the thread behind that.
> _______________________________________________
> dispatch mailing list