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

Samuel Erdtman <> Fri, 30 April 2021 21:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 88D933A27C3 for <>; Fri, 30 Apr 2021 14:37:51 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 n6WaK8MhdQD0 for <>; Fri, 30 Apr 2021 14:37:46 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5FF2D3A27C4 for <>; Fri, 30 Apr 2021 14:37:45 -0700 (PDT)
Received: by with SMTP id l17so40072103oil.11 for <>; Fri, 30 Apr 2021 14:37:45 -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=w1Q1xCyUlS5YecimIPNpEdvwo4WoaGXjHkYy0ET4Gq8=; b=G+5BD/4+MSxUlOssMP9ekqqDkHdKas3UOPNUHa9qTsD1njDIGILR2CXOKcZRM055pA OLrbqTVKHeKNhfK4UsqC3/PevtsnBCwPCr8fGtmR5rzEINGvPO5Q+wdxV2cC3Q/GxGy3 t7AOwr/zui2SpmsFO/Y9vpqw9XAkygpPVbX6SArALx1pCRHs1W/9sLh90JWaq4SRtNJs m8IqKfHNznC+OJ0vMDnsVD1Og3WuMmio9QgEy99Cy1sMu9XlBRK2M5f5w0KQHdMlAV/b ORzQ4KW8tGDRXoNySTFW4BDxH+4cOEni7UwkzVkPOt5HaUfglfGcK0HNDzQ332UYxbe2 gLLw==
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=w1Q1xCyUlS5YecimIPNpEdvwo4WoaGXjHkYy0ET4Gq8=; b=JlQaOcKTohQe0OOP4x2oVGS9mSCUWG2BcE0WuRnivzDYAxub2AyF0+T4QUeXlZ6HbI jUcPLe0k5Lq2j6grbdJ7gTNaQmholsiTSfRwevEMxx1Ljd5cOSDCxRiptV4JylqJ9Fbo RBt3gAKn2/hFUDeNgTzD1M6Y/1/hKms72KpLdEy2lZNU2XP47gMyz5Cm77LtgQbUoZcc Qn64jRSrEU1RPHp0XiDpkDkvVaQaNJz/FiHmKZcYxndQi9eGIzYcpVYQUYehFC4zEYgc E7COGwtr4TJ2pv5RuJtcXB+bMn4h/Tzjghks2dBfgwnG3mCLqv7G3R19vxR0j9Uj7o3z Auqw==
X-Gm-Message-State: AOAM533/yxWrhlI9ZVi0rT1jDVqgB+gmldcl7Cg0Pqz4IQxOYAIcKiIi xEvdMaRWrAYQH7Vi0q0/H9b4niDR4YhBWVPyB/RmKR3Mb3WJ2A==
X-Google-Smtp-Source: ABdhPJzbixKWZxm7UKJpZ9r8taFjtGVuQHCHeq99EycD1ixd5lv2sZMGeIN4XADlSjaajU5RSPpCWY5CVSPWGbNPsiE=
X-Received: by 2002:aca:b9c1:: with SMTP id j184mr5470835oif.134.1619818664336; Fri, 30 Apr 2021 14:37:44 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <> <>
In-Reply-To: <>
From: Samuel Erdtman <>
Date: Fri, 30 Apr 2021 23:37:32 +0200
Message-ID: <>
To: Carsten Bormann <>
Cc:, IETF SecDispatch <>, DISPATCH <>, "RFC ISE (Adrian Farrel)" <>
Content-Type: multipart/alternative; boundary="00000000000016ddaf05c1376c64"
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: Fri, 30 Apr 2021 21:37:52 -0000

Hi Carsten,

Thank you for sharing your thoughts.

I´m not sure I understand your point, maybe you could elaborate a bit (I
have some questions).
1. What do you mean with data at rest, data store in database or file? Or
is it data that does not change? Sorry I do not get it.

2. What is weird with saying "Represented in JSON"? 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)

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?

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.

Best regards

On Wed, Apr 28, 2021 at 5:56 PM Carsten Bormann <> wrote:

> 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
> _______________________________________________
> dispatch mailing list