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

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

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2C1B33A1132 for <>; Sat, 1 May 2021 14:28:49 -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=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id YZ5aQfbNJhBZ for <>; Sat, 1 May 2021 14:28:44 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::c2d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4F9883A1115 for <>; Sat, 1 May 2021 14:28:44 -0700 (PDT)
Received: by with SMTP id u48-20020a4a97330000b02901fa060b8066so414687ooi.8 for <>; Sat, 01 May 2021 14:28:44 -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=Y4K4ms5W8oP/nQiUlcLgssDNUjb+LAcb6PIJKQKny+k=; b=Eb32Jz6yq6vjlMaTlINLMTCO6FugVBqu5wlm6mrd75++tPyl+vNaCtU+30QGBJPnYZ fauGDJfqRgM6VInysuRcHf/3NlvycRggApYeUf3bbdImKMsQ441k81UGpdAM+T8wvEz2 TFREOGi19qSDUR7FaWECTWA8ieZ111NBemIXMddAJkI80CKxHHZwasugIyKpwIik7k0M nFwrRr+pbzF4VR1fP1yWVBfrQ+idShzPB3ycbYGCnExx0e9iwD0TC+/RbpKxcguw8lfc ohUvfK589ZmZ4m10koO7tDveVGGkYa3IeQ0HVxZueFJX5gO9M4DjeQD7Y0SmtfygInnr d+9w==
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=Y4K4ms5W8oP/nQiUlcLgssDNUjb+LAcb6PIJKQKny+k=; b=AgvwFiVjjADWMiTer1zvO1OHz/Pv+bSfPUVaqk2MZtCAu4ls+Q9sGh4rpP4CLsyesw /xWi317Map8v86Q/ksdRHgLANs4Q22zSGz0Yau8o85vnDhR5rkZ11uyTwqJ69EUOuYfQ khZiFIffqshmUhCij+SAn2SuvaxH5ogSvlA5SEElBUggnBdmr6rTYVaoQRWM/oa+Rl9e kDcuiU3MOeEjIYAQmt0uljlmPP97JhuVAmHPwfGK4zhNaR2wJf8yuzhPmTeIfzdEO3Ca 8tCaBBCoPypqNJf0cwMN1x8t3puWugLBW2HLDzqZvFLcDp7qcbNw+GRo9Y+uVZNzCxYo kTsA==
X-Gm-Message-State: AOAM533xNpOWQWjK7fVgcc6p+ZTDzYYx6xPVvgKOe5/wIvgh5scrjbNv 8pDVf6e3UgUutR3b9mnqqsO75KhJl93E05Dtl5vVKg==
X-Google-Smtp-Source: ABdhPJxmJocMe3Ac8LH7n3q9RzZpe1UNPN64HisJO5XfBtgT9anrX8GTpZ4ePTU8l7a4TFeqZ4aYxAeopZv4Q74MT08=
X-Received: by 2002:a4a:b4cb:: with SMTP id g11mr9851682ooo.41.1619904518286; Sat, 01 May 2021 14:28:38 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Samuel Erdtman <>
Date: Sat, 01 May 2021 23:28:27 +0200
Message-ID: <>
To: Carsten Bormann <>
Cc:, IETF SecDispatch <>, DISPATCH <>, "RFC ISE (Adrian Farrel)" <>
Content-Type: multipart/alternative; boundary="00000000000062079105c14b6910"
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:28:53 -0000

Hi Carsten,

One more thing, you wrote "Signing data at rest certainly is a use case
that is worth addressing.". With my new fond insights (thanks) does this
mean that you are in favor of specifying how to do enveloped signatures for
JSON (or at least not against it)?


On Sat, May 1, 2021 at 11:24 PM 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).
>> > 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.