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

Samuel Erdtman <> Sat, 01 May 2021 21:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D02183A10E3 for <>; Sat, 1 May 2021 14:24:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 bQZXlZ2mVcX0 for <>; Sat, 1 May 2021 14:24:36 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::330]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E49C23A10DB for <>; Sat, 1 May 2021 14:24:35 -0700 (PDT)
Received: by with SMTP id z25-20020a9d65d90000b02902a560806ca7so1691018oth.11 for <>; Sat, 01 May 2021 14:24:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/A8fC/y06IUQCpxXUtnwqNKNMEXAPLVQIgkwFkVzgKc=; b=11G7EeuMT2OVhfIffPfFwkJzJlhvMGddlmi9rM9TWu2Qn+YgfmJp/Se8B8lqGuRVcK 5tdrmKGsHUBfJIYzPQnbntfIdvbdSXDDyPHB0OoQpGgKLt2KcOmfOC9c7QxZhMT9PH8Y F6fqkrk5FL5/ipF9nM0HEUJM/D7kzn/9OPKJcBoAuyrzjdszVaMD5DlCX1QaCxx319dI rFUzwgCKENwNUGxtTVjCVGSDwFt7UWqXr8IkqCmZehME6ni2YtLQ/Or29IbcbSlGhepO pHPjRcX2BvHg2yDnrZhx8pmL7kXqkGPWoDrwV0JztgcXbu4U8+X8GmEU9K/uSe6y0HQV hWjw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=/A8fC/y06IUQCpxXUtnwqNKNMEXAPLVQIgkwFkVzgKc=; b=surogh4pw3k6GT4IsEKxeE6y5gaTJ8E2bTnfKNTEq/J3wcWkzGXTglbObb3uRAl2mo ThvwdghSiKw0d0gyN2AJAKbdCCyYl2bdiSeLfVhpMSsTw6UCVS3SoQY5VHTkddGrVpIH 8H+nY+du/3OOba8br/Hq0uli9N7bLe6FMvuzNCeIkSxr6kotkZZoGP9r8eDKNPNVKnkw pWlRNtn2jmm9GM1YecbKUeEsk4seiHyZkKIKWwvwCMl1LGnvvHhmimiH6Jse/+Ba2E2V aystJQC0R1cH0mX01Qacfmb3qyv7FpZPFVakAVuRkGCT+NiLSnFI4MQe6pAiBp/71ASM bliQ==
X-Gm-Message-State: AOAM532kD+ImfkmFLjTG1ckw9b+uBETDKTClw/IwIrB/7huYKoPvJHGR nN2wQpDPodYr4U7d4nkHN6FJ2G9cb7s20UW3Q6N8RGfmqvHqcA==
X-Google-Smtp-Source: ABdhPJw/XGFSI7GGw9rZNxUUOAdVfwa8GivwmhyCLXi8eL6riv//NGsByNKYt9FhJPHTLuajOltpyTYum73w1Z3OuOc=
X-Received: by 2002:a05:6830:4ca:: with SMTP id s10mr9304681otd.79.1619904273973; Sat, 01 May 2021 14:24:33 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Samuel Erdtman <>
Date: Sat, 01 May 2021 23:24:23 +0200
Message-ID: <>
To: Carsten Bormann <>
Cc:, IETF SecDispatch <>, DISPATCH <>, "RFC ISE (Adrian Farrel)" <>
Content-Type: multipart/alternative; boundary="000000000000d212eb05c14b5aeb"
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 21:24:41 -0000

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

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

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

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

Fair point

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