Re: [dispatch] IETF 116 - do you have something for DISPATCH? Thu, 02 March 2023 17:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E0F16C13A356 for <>; Thu, 2 Mar 2023 09:05:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.981
X-Spam-Status: No, score=-5.981 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_SOFTFAIL=0.665, 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 DWB2QNWwvJbI for <>; Thu, 2 Mar 2023 09:04:57 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EAF44C15DF69 for <>; Thu, 2 Mar 2023 09:04:56 -0800 (PST)
Received: from ([]) by with ESMTP id Xj93pDOZuNhMeXmKUpqhoq; Thu, 02 Mar 2023 17:02:54 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20211018a; t=1677776574; bh=J/TJfT5K/CMB7viKjAs72EvYw/uXmACclVcqhFsev9M=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID:Xfinity-Spam-Result; b=OspCgmiqjO7j2+mmKhPlNfbeHNlQYDBgcmWlqfLE9hWrFuomU2wR1N9+o0IQ1ABsA W/bIJEp6DAQt2jQ0Xplh1mY+KMW1iLzPt/3nWScAOTu9YGqI7HV3tuixns2l7SLQWI 32ygtTJ0e0QZJhh9xVHJlAZnRnaclSYuv6nFmnNOyiT1IyliQ/TSIBgyY/zpxyQ/z0 zrReEvcLEFUfqjMmuY3ZC/wy1OPObmv8YoXbvj1u2+6mruR03d8vvnf5GcJx3zVqnX KzbSS1EOVOXB8zzTE5LhxWwPN7R5+PpI+Ae4UA89tBzPScY00Pxss36vg2s1jEekL9 ZUaYnVdz+etEQ==
Received: from ([IPv6:2601:192:4a00:430::9e4e]) by with ESMTPA id XmK6pKtIDxJ34XmK7pIQaF; Thu, 02 Mar 2023 17:02:32 +0000
X-Xfinity-VMeta: sc=-100.00;st=legit
Received: from (localhost []) by (8.16.1/8.16.1) with ESMTPS id 322H2UtC3147144 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Thu, 2 Mar 2023 12:02:30 -0500
Received: (from worley@localhost) by (8.16.1/8.16.1/Submit) id 322H2TKG3147141; Thu, 2 Mar 2023 12:02:29 -0500
X-Authentication-Warning: worley set sender to using -f
To: Christopher Allen <>
In-Reply-To: <> (
Date: Thu, 02 Mar 2023 12:02:29 -0500
Message-ID: <>
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: Thu, 02 Mar 2023 17:05:02 -0000

Christopher Allen <> writes:
> 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. [...]
> 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.

Contacting the chair(s) of the CBOR WG(s) would be a start.  You might
also search the IETF mailing list archive for "dCBOR" and "deterministic
CBOR" to see what mailing lists have discussed it.  Or joining any
relevant WGs and posting notices to their mailing lists.

> 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.

I've followed the CBOR work some, and in general there's no shortage of
tags.  So registering it early is likely to be OK.  I see from that tags
<32768 are "Specification Required" and tags >=32768 are "First come
first served".  That suggests that if you expect to use a tag, and the
tag already has a clear, frozen definition, you might as well register
it now with its specification.  This works especially well if the tag
may have uses in other applications.

OTOH, if further work on Gordian Envelope is likely to change the
details of the specifications of your tag, you aren't violating the
rules if you register it FCFS; few will care if you update the
definition or abandon it entirely.  (Does the length of the tag matter
in your usage?)

("Gordian Envelope" sounds similar to letterlocking, which has been in
the blogosphere recently!)