Re: [Rats] [Cbor] I-D: draft-rundgren-cote-00

Carsten Bormann <> Tue, 19 July 2022 14:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A076DC18870E; Tue, 19 Jul 2022 07:06:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.907
X-Spam-Status: No, score=-6.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id FMFd2eGXBr0P; Tue, 19 Jul 2022 07:06:46 -0700 (PDT)
Received: from ( [IPv6:2001:638:708:32::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 (Postfix) with ESMTPS id 45794C182D6D; Tue, 19 Jul 2022 07:06:44 -0700 (PDT)
Received: from [] ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 4LnLH31wPRzDCdm; Tue, 19 Jul 2022 16:06:39 +0200 (CEST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
From: Carsten Bormann <>
In-Reply-To: <>
Date: Tue, 19 Jul 2022 16:06:38 +0200
Cc: Anders Rundgren <>, "" <>,
X-Mao-Original-Outgoing-Id: 679932398.6892689-5e2e68eff82782f4d47573f04fedbe58
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <>
To: Christian Amsüss <>
X-Mailer: Apple Mail (2.3608.
Archived-At: <>
Subject: Re: [Rats] [Cbor] I-D: draft-rundgren-cote-00
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Remote ATtestation procedureS <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 19 Jul 2022 14:06:50 -0000

On 2022-07-19, at 15:52, Christian Amsüss <> wrote:
> Signed PGP part
> Hello Anders,
> On Tue, Jul 19, 2022 at 02:40:37PM +0200, Anders Rundgren wrote:
>> Since I did neither make it to Philadelphia nor to the cut-off date,
>> here is a private publishing:
> Sounds reasonable to me, two comments:

Agreeing with the below comments, but if I had my designated expert hat handy, I would say:

This is underspecified as the specification does not really spend any effort ensuring that the type identifiers are unique to a specific usage.  This is likely to lead to interoperability problems.  I would think a few more things could be said about the type identifiers that would reduce these hazards.  Re the example given: URLs in general are surprisingly bad as stable identifiers, while a few specific forms exist that are much better.

> * Given that there are full URIs in there, compactness is barely a
>  concern. Thus, I'd appreciate if you asked for a tag from the range
>  above 256.

Indeed.  Going above 32768 would also take the designated expert out of the loop, so the format can be as foolish as one wants :-)

> * Please consider what of RFC 6648 applies here. When would a protocol
>  author pick a type extension over a tag, and what would happen if such
>  a type extension becomes popular outside the community or application,
>  and maybe users push for registering an equivalent registered tag?

This is part of a fundamental problem in a totally open type identifier system: Why would the generator spend effort fitting into an existing type when they can simply create another identifier?  Such a system should instead nudge its users towards behavior that is in favor of more interoperability.

I think we found a pretty good way to handle this problem in — yes, we do allow URIs in certain places, but we are even proposing a good class of URIs in the example.

Grüße, Carsten