IETF Logo Mail Archive

Re: [Cbor] Deterministic CBOR as a possible DISPATCH item

Carsten Bormann <cabo@tzi.org> Mon, 06 March 2023 20:52 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: cbor@ietfa.amsl.com
Delivered-To: cbor@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A735AC14CE46 for <cbor@ietfa.amsl.com>; Mon, 6 Mar 2023 12:52:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nUvdhUespXqd for <cbor@ietfa.amsl.com>; Mon, 6 Mar 2023 12:52:29 -0800 (PST)
Received: from smtp.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [134.102.50.15]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 343F9C14CE2C for <cbor@ietf.org>; Mon, 6 Mar 2023 12:52:27 -0800 (PST)
Received: from [192.168.217.124] (p548dc9a4.dip0.t-ipconnect.de [84.141.201.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.uni-bremen.de (Postfix) with ESMTPSA id 4PVrP56XVJzDCbV; Mon, 6 Mar 2023 21:52:25 +0100 (CET)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <CAAse2dFgsHP-kpu-vgfc0JbSvzL9PEG5+0FTE-xVAWfvqBQycg@mail.gmail.com>
Date: Mon, 06 Mar 2023 21:52:25 +0100
Cc: Laurence Lundblade <lgl@island-resort.com>, Wolf McNally <wolf@wolfmcnally.com>, Anders Rundgren <anders.rundgren.net@gmail.com>, cbor@ietf.org, Shannon.Appelcline@gmail.com
X-Mao-Original-Outgoing-Id: 699828745.590441-77690f07e72bf5f0c3d9e2cebec12e6a
Content-Transfer-Encoding: quoted-printable
Message-Id: <332B3669-74AC-49EF-9CDC-3C4470766CA9@tzi.org>
References: <A9CF043D-4FA9-48D4-B953-3BE7AA40D1E0@tzi.org> <D25A0C94-ADAD-4C3D-8669-AA7FE9A6B3C4@wolfmcnally.com> <FA0E2D22-37F4-4C27-B5F5-E841D13EF0CF@tzi.org> <1DA00A88-64DF-48FD-B03E-10B520934DD2@island-resort.com> <3D57170C-61E4-4192-8B5F-120134ADA964@tzi.org> <F16409C6-81FF-4C99-A465-0BE1C07AD603@island-resort.com> <CAAse2dFgsHP-kpu-vgfc0JbSvzL9PEG5+0FTE-xVAWfvqBQycg@mail.gmail.com>
To: Christopher Allen <ChristopherA@lifewithalacrity.com>
X-Mailer: Apple Mail (2.3608.120.23.2.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/fSFDji31Y4esoDXlL3Z5AGGuSpw>
Subject: Re: [Cbor] Deterministic CBOR as a possible DISPATCH item
X-BeenThere: cbor@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Concise Binary Object Representation \(CBOR\)" <cbor.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cbor>, <mailto:cbor-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cbor/>
List-Post: <mailto:cbor@ietf.org>
List-Help: <mailto:cbor-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cbor>, <mailto:cbor-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 06 Mar 2023 20:52:33 -0000

On 2023-03-06, at 21:44, Christopher Allen <ChristopherA@lifewithalacrity.com> wrote:
> 
> when I asked around very early on for a review of the Gordian
> Envelope spec among my former IETF colleagues (I was editor of the TLS
> 1.0 spec in the 90s), the almost universal response was "why not just
> use JSON?".

If I had a cent for each of these responses :-)

One of the reasons why complex derivation of signing inputs is justifiably disliked is that it is easy to build issues into that derivation process that make it hard to determine what has actually been signed.  (Well, yes, the signing input, but what does that actually say about the semantics of the data that went into that derivation and that people *think* they have signed?  Often, these processes provide too much wiggling room for an attacker.)  

If your protocol achieves full clarity about that, more power to it.

Grüße, Carsten

v2.37.1 | Report a Bug | By Email | System Status