Re: [Cbor] Unusual map labels, dCBOR and interop

Wolf McNally <wolf@wolfmcnally.com> Thu, 28 March 2024 07:00 UTC

Return-Path: <wolf@wolfmcnally.com>
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 1D2E4C14F73F for <cbor@ietfa.amsl.com>; Thu, 28 Mar 2024 00:00:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.893
X-Spam-Level:
X-Spam-Status: No, score=-6.893 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_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=wolfmcnally-com.20230601.gappssmtp.com
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 TzE6Fa6ZMl1b for <cbor@ietfa.amsl.com>; Thu, 28 Mar 2024 00:00:47 -0700 (PDT)
Received: from mail-pj1-x102f.google.com (mail-pj1-x102f.google.com [IPv6:2607:f8b0:4864:20::102f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 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 9A706C14F714 for <cbor@ietf.org>; Thu, 28 Mar 2024 00:00:47 -0700 (PDT)
Received: by mail-pj1-x102f.google.com with SMTP id 98e67ed59e1d1-2a074187a42so495639a91.0 for <cbor@ietf.org>; Thu, 28 Mar 2024 00:00:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wolfmcnally-com.20230601.gappssmtp.com; s=20230601; t=1711609247; x=1712214047; darn=ietf.org; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:from:to:cc:subject:date:message-id:reply-to; bh=Ijs19S5R5baumpU5ElMGjdIVt1m5XYVCCopTOMd4/B4=; b=nrdZEeTeiFwHoPlglIre9kfDsiXStqwg67wx4zmtU+GZGRO6+p1iiqFIkABQmd79Xd TJ0gK1TaUxuN/vRV1zUAPruyuAnnIngKcHgRLuGRq9ZIcnqp+UA4LCqlJr9mkHdigiXe dvD/N0VYN3ncfd9yD3LzotGyaRZPFiSPp9DCCsTxeRqRLFVixZ4nTigwJ34q3Ii89G5i Qt76z2NpodbsUzm7QL4lZDIFnN8Mslh89hnbTs/8t2Me5ZFPwF++b1oltkMQZXzoA0sg zB66h2WNvOX24SvKQoAyotBtjcUL0ucbbEms1R/TTAshePp8eJaYQXYtorr6k17niygU 1sIQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711609247; x=1712214047; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=Ijs19S5R5baumpU5ElMGjdIVt1m5XYVCCopTOMd4/B4=; b=PLHUH5agCx0dcdX287Ir/HNCdhP9CaGdXg+rMhLd7hiSlg4kyXUpmqWK6STPdy6bzB KeT6DnWjDAqDoXygu2IMOKnJaN8QefyptJ5PRaFU1bRJGivkMOVf7QgMGQyzIlrvLH9V yMyPOPTBoKT6e/rkJ/00sKMeYCgr3dyPblAcIB7vwo/9fw0Xph6UbpQMZQcWtbSIRDVi uDymszva3MvUq9j7LYRW6Sc5yQjPhp7bK7Wdgh0wuNzG8XX2Z3Xj21zHf4AvYBLul2Pm XqA3t7aj/m7FvtbZVEKd1XJNSJeDSelOdrkOvzL+E7Dl1T/Eh6N69QIU3mphi8Dg+IJQ vN7A==
X-Gm-Message-State: AOJu0YzCZn+DcWzec453FEdLcd7qI34vRO/JhbWR5AETvPQxe+cFKiaS jDt6k7Jb6kUXqeLJR2ZZeVhLe722vyzBV8uvf5SZ8msQAnkSzKNu/YcyWM3bdbUcSKiP15BFUAt ejJk=
X-Google-Smtp-Source: AGHT+IEfayZ1Q2v2218vvVoCdwiKSHy9PGSAoXj9rOQp8UlY1Vj2NkoQbZG1+1xl7uZar1L80bn3lg==
X-Received: by 2002:a17:90a:680e:b0:29f:be68:5cf6 with SMTP id p14-20020a17090a680e00b0029fbe685cf6mr1706405pjj.12.1711609246569; Thu, 28 Mar 2024 00:00:46 -0700 (PDT)
Received: from smtpclient.apple (ip70-180-193-108.lv.lv.cox.net. [70.180.193.108]) by smtp.gmail.com with ESMTPSA id v12-20020a17090abb8c00b0029c13f9bd7fsm2800604pjr.34.2024.03.28.00.00.45 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 28 Mar 2024 00:00:45 -0700 (PDT)
From: Wolf McNally <wolf@wolfmcnally.com>
Message-Id: <B53F373E-4997-4654-AB56-7719EF0ADD99@wolfmcnally.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_18F86605-B0B5-4E44-AB14-5A67E3A4F963"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.500.171.1.1\))
Date: Thu, 28 Mar 2024 00:00:33 -0700
In-Reply-To: <03144212-69bd-441e-8697-fdf1fd9f9689@gmail.com>
Cc: cbor@ietf.org
To: Anders Rundgren <anders.rundgren.net@gmail.com>
References: <8C245824-1990-4616-AB70-FFD4FACB1AE9@island-resort.com> <11E8A8A5-D891-49FF-AF16-697C06F463B3@tzi.org> <9A0CE364-C141-4EBE-9703-292C416D12F5@island-resort.com> <3D62C4F0-D570-4EE4-AF6A-163C708AA6BE@tzi.org> <58BA8F8C-0C63-4534-9BF7-255C32D02C16@island-resort.com> <CAN8C-_KCLv_cAt-0-C_=i6DXjZFkgkmgZ8DNq48RcxcvV+jEUQ@mail.gmail.com> <437a375c-49e8-4406-a192-acb9a5e7bf31@gmail.com> <9272C2ED-432D-4D6D-AB64-38976F9297D5@wolfmcnally.com> <794fae9f-1c87-498b-aaea-4e476b0dc420@gmail.com> <C24BFA9D-D19C-4267-B0C8-54842B124452@wolfmcnally.com> <03144212-69bd-441e-8697-fdf1fd9f9689@gmail.com>
X-Mailer: Apple Mail (2.3774.500.171.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/cM-Ufhk2wxUX-c-GtaQOKW9GRjw>
Subject: Re: [Cbor] Unusual map labels, dCBOR and interop
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: Thu, 28 Mar 2024 07:00:53 -0000

Anders,

> On Mar 27, 2024, at 11:23 PM, Anders Rundgren <anders.rundgren.net@gmail.com> wrote:
> 
> Wolf, we are in full agreement!  However, CSF (CBOR Signature Format) does pretty much the same things modulo "elision" as Gordian Envelopes, builds on CDE:
> https://test.webpki.org/csf-lab/home

It is a mis-characterization of Gordian Envelope to compare it to a “signature format” even “modulo elision". Envelope is a hierarchical binary document format built on dCBOR, that in its simplest form (as described in the I-D) supports elision (useful enough in and of itself), and in that simplest form actually has no specified way of handling signatures at all.

But Envelope also has various optional extensions (with reference implementations), many of which benefit from or rely on determinism, that support:

- Full or partial signing (embedded or detached)
- Holder-initiated elision (without invalidating signatures)
- Arbitrarily deep metadata based on recursive semantic structures
- Full or partial symmetric encryption (without invalidating signatures)
- Full or partial public key encryption (without invalidating signatures)
- Sharding using Shamir’s Secret Sharing (distributed/social backup)
- Digest decorrelation
- Inclusion proofs (progressive disclosure, herd privacy)
- Sealed transaction protocols
- Compression (without invalidating signatures)
- Diffing and merging

I suppose in a way I should thank you for your persistent mis-characterizations, because in doing so you give me the opportunity to introduce this technology to newcomers to the list.

https://www.blockchaincommons.com/introduction/Envelope-Intro/

~ Wolf