Re: [dispatch] IETF 116 - do you have something for DISPATCH?

Anders Rundgren <> Sun, 05 March 2023 07:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 12AADC14CE54 for <>; Sat, 4 Mar 2023 23:51:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7Wma077T_S4B for <>; Sat, 4 Mar 2023 23:51:41 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::32b]) (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 (Postfix) with ESMTPS id 7DF3FC151527 for <>; Sat, 4 Mar 2023 23:51:41 -0800 (PST)
Received: by with SMTP id az36so3897868wmb.1 for <>; Sat, 04 Mar 2023 23:51:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; t=1678002699; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=aUZfccjNqQf5dWqnQRWGXAg3ulYi2+J2phO6Gur3K/w=; b=mn/APU3mBzfSDfcoBUJKkpGbWDbrz8PJChothgUlFQ2BAa7gkB/vAD3fQoCPtUbxp0 qTEsyynMpXhA1AgX0+BcKI7l9PAagn1oPCz5jKyZbWKAcH4imZQZS9x7M6DUZe0ad/BS YTBbCqi8FcVpb7yY89p1ZlphapDWu2XUsa1d9r3EuQiUYMv+YP2XKdNiCvbCN8x89wIG /xv9JV/JirWWybCP1y5yxMnEZCKAPYZaj31yRS0PETwlobpvh0JyyD3a15zkCvQReojn wFAauy7YoDeCm1ut5tOoJu/UeaYPiWsW4MvrxAu3X7wldO5QYU3D5HKTv9oxSfJuqiRu IEcQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; t=1678002699; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=aUZfccjNqQf5dWqnQRWGXAg3ulYi2+J2phO6Gur3K/w=; b=zXU3ghiMuplcvnM93KWqxUsyye1U3paehH5nCdyawlMPyFZlHSJBfIzLRoiPDnHJLu MqIws3d4EDc2HWIUYROB9x5ZyywCwp2ipMdrwhmQm51ike3ZnlAe5c4C+Yo7sNzYrQqw vs4Zzji78Jb8yUjD7eH8gSxvANF4JUTE2PE15dGh6DFuYWXnwD+dT3dcpjOXdtDGde3k 9+JpIHdwkEiJLGf7NPwM1tbPkeWiiE+dpAPK8JfRo5gW/BqDVVwL2+XA3HmtVi8kxJZD BPK3s9/nubGbGt68yJF392lczURByZE8optB9BS95GUlI30/z5BBfYjxVRrCxpEt6TU2 Sucg==
X-Gm-Message-State: AO0yUKWsxwp+mfekVJ4i9JzGoKoPLEct4xCGQXSFYjhCOaYGGGb1+c2W ijCfMlgs6bVjjBT/w4Wm00rXTvxDi0Q=
X-Google-Smtp-Source: AK7set9xoWYdNb2m0NMOS3rLT/zjx83VeoFZ7cH4xR4J97dPAJXnq1j0pAdVFN3FoXPF0z3LIN/9Uw==
X-Received: by 2002:a05:600c:3505:b0:3ea:f883:53ea with SMTP id h5-20020a05600c350500b003eaf88353eamr5787801wmq.7.1678002698950; Sat, 04 Mar 2023 23:51:38 -0800 (PST)
Received: from ?IPV6:2a01:e34:ec4e:5670:2439:9550:6ec8:51ee? ([2a01:e34:ec4e:5670:2439:9550:6ec8:51ee]) by with ESMTPSA id x8-20020a1c7c08000000b003eb2e33f327sm16228894wmc.2.2023. (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 04 Mar 2023 23:51:38 -0800 (PST)
Message-ID: <>
Date: Sun, 05 Mar 2023 08:51:37 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.8.0
Content-Language: en-US
To: Christopher Allen <>,
References: <>
From: Anders Rundgren <>
In-Reply-To: <>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <>
Subject: Re: [dispatch] IETF 116 - do you have something for DISPATCH?
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: DISPATCH Working Group Mail List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 05 Mar 2023 07:51:46 -0000

On 2023-03-02 6:02, Christopher Allen wrote:
> On Tue, 21 Feb 2023 06:40:27 +0000 "Pengshuping (Peng Shuping)" < <>> wrote:
>     It's that time again - we're calling for agenda topics for our next meeting at IETF 116 (25 - 31 Mar 2023). No matter how big or small, if you have something you'd like dispatching or that you think will be of interest to the ART AREA, get in touch and get involved.
> My name is Christopher Allen. I’ve worked with IETF previously as the editor of the TLS 1.0 standard, but it’s been a number of years since I've been actively involved with IETF — most of my recent standards work has been with the W3C.
> I’m now the Principal Architect of Blockchain Commons, and I would love to join your agenda for Dispatching a new project.
> Blockchain Commons is working on Gordian Envelope, a “smart document” that supports the secure, reliable, and deterministic storage and transmission of data such as seeds, keys, decentralized identifiers, and verifiable credentials in a way that enables privacy while preserving structure.
> We’ve submitted it as an IETF Draft (and plan to have -01 submitted before the I-D deadline this month):
> <>
> Here are some general thoughts:
> PROBLEM STATEMENT: Current document formats don’t focus on a user’s ability to use elision, encryption, herd privacy, and other methods to preserve the privacy of their data in a granular way.
> EXISTING INTEREST: Several companies have seen the need for these capabilities and have been participating in regular meetings on the topic. ( <>)
> INTENDED DELIVERABLE: We want to produce a revised draft with more community input to ensure that the specification meets the requirements of a larger community.
> We’d like to present on Gordian Envelope to Dispatch and get the best advice on how to move forward. We would obviously like to work with groups who might want to make use of Envelope for its privacy-preserving document format. We also think we have critical mass on the US west coast to justify a BOF there and would like to see if Dispatch would be interested in supporting that.
> As part of our work on the Gordian Envelope, we embraced deterministic CBOR (dCBOR), which is the foundation of Envelope. dCBOR is an optional variant of CBOR that lies in the CBOR spec but hasn’t been widely used. Because determinism is very important for the hashing that we use at the center of the Envelope format, we’ve created and released what we believe are the only reference libraries focused on dCBOR as part of our intersectional work on the topic. We’d love to get advice from Dispatch on how to work with other CBOR-focused groups who might be interested in the work we’ve done to support the deterministic subset defined in the IETF CBOR specification. (We’ve tried to contact some on our own, but we appear to getting stuck in email filters.)

The definition of a usable subset of CBOR supporting deterministic serialization would IMO qualify as a separate DISPATCH work item:

> Finally, we would like advice from Dispatch on the best way to register our cryptographic-focused CBOR tags used in Envelope with IANA, namely whether we should do so now, or whether we should wait for later in the IETF process.

Before you do, I would not rule out
which I hereby propose as a DISPATCH work item.


> Thank you very much for your advice and support. Please let us know of anything else we can tell you and what else we’d need to do in order to schedule a presentation with Dispatch.
> -- Christopher Allen
>     Blockchain Commons
> _______________________________________________
> dispatch mailing list