IETF Logo Mail Archive

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

Carsten Bormann <cabo@tzi.org> Mon, 03 May 2021 15:37 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: secdispatch@ietfa.amsl.com
Delivered-To: secdispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1446D3A18A5; Mon, 3 May 2021 08:37:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.918
X-Spam-Level:
X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id quKJ_zcHgsmb; Mon, 3 May 2021 08:37:41 -0700 (PDT)
Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 366BF3A18A3; Mon, 3 May 2021 08:37:41 -0700 (PDT)
Received: from [192.168.217.118] (p548dcb12.dip0.t-ipconnect.de [84.141.203.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4FYnD23HSWzyVM; Mon, 3 May 2021 17:37:38 +0200 (CEST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.6\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <CAF2hCbaMz26X4m2vshVzJXkeDWia-53oTocHvxJ4a+1M_=-zAg@mail.gmail.com>
Date: Mon, 03 May 2021 17:37:38 +0200
Cc: DISPATCH <dispatch@ietf.org>, art@ietf.org, IETF SecDispatch <Secdispatch@ietf.org>, "RFC ISE (Adrian Farrel)" <rfc-ise@rfc-editor.org>
X-Mao-Original-Outgoing-Id: 641749057.865182-4f28f307c53c71d76f6553ebffc36dbc
Content-Transfer-Encoding: quoted-printable
Message-Id: <B48FA387-B5E1-4191-B0C3-B92132B18399@tzi.org>
References: <CAD9ie-v7uJOpjj+nbZCfQe+4JEQt-6=b6cm57iFPAn_enGeRCQ@mail.gmail.com> <3B394519-4061-43A8-8963-55A6ADEDF269@gmail.com> <19a99964-8495-2de9-b49a-52aa8321c12e@aaa-sec.com> <220475a6-1e04-107e-6327-366d48d8b420@gmail.com> <27833d9d-53c3-d01c-b01c-e7d53424b5ab@aaa-sec.com> <A88D122C-C1EB-477B-A83C-A22F1BB3CC47@gmail.com> <B8E5AF13-7B59-4329-890F-2B14766032A5@tzi.org> <CAF2hCbahPMAwe_63dT+pcz2BZSy0XOPstXqpxsCq1Vj0UmSDPg@mail.gmail.com> <1B4304D2-E82E-4255-B10C-F29ABCABE15E@tzi.org> <CAF2hCbaAx00dxxb2jRmQzVBaW7yyhefQ33+yt0uHwvwt+W_hfw@mail.gmail.com> <CAF2hCbaMz26X4m2vshVzJXkeDWia-53oTocHvxJ4a+1M_=-zAg@mail.gmail.com>
To: Samuel Erdtman <samuel@erdtman.se>
X-Mailer: Apple Mail (2.3608.120.23.2.6)
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdispatch/C8XZSO1tKM05_WtjP8bLQJ0h7X0>
Subject: Re: [Secdispatch] [art] [dispatch] Plain text JSON digital signatures
X-BeenThere: secdispatch@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Dispatch <secdispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdispatch>, <mailto:secdispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdispatch/>
List-Post: <mailto:secdispatch@ietf.org>
List-Help: <mailto:secdispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdispatch>, <mailto:secdispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 03 May 2021 15:37:46 -0000

On 2021-05-01, at 23:28, Samuel Erdtman <samuel@erdtman.se> wrote:
> 
> 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)? 

Signing data at rest doesn’t mean that the signature then needs to be put into the signed object.  This is essentially adulterating that object, and is part of the XMLDSig “what was just signed?” practicability issue.
(Such as, does my countersignature include the previous signature or not?
What does it mean to sign a signed object?  Nothing about the existing signature, or does it mean I endorse the existing signature, or does it mean my signature actually is conditional on the validity of that existing signature?)

I’m not sure though I know what an “enveloped signature” is, and whether what I just said above even replies to what I asked.

Grüße, Carsten

v2.23.0 | Report a Bug | By Email