Re: [Cbor] Benjamin Kaduk's No Objection on draft-ietf-cbor-tags-oid-06: (with COMMENT)

Carsten Bormann <> Thu, 08 April 2021 08:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 325DE3A3F3A; Thu, 8 Apr 2021 01:00:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.92
X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id haFnJvl8IU4G; Thu, 8 Apr 2021 01:00:28 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 876AD3A3F39; Thu, 8 Apr 2021 01:00:27 -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 4FGDG12hLwz17ZX; Thu, 8 Apr 2021 10:00:25 +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: Thu, 08 Apr 2021 10:00:24 +0200
Cc: The IESG <>,, CBOR Working Group <>,, Christian Amsüss <>
X-Mao-Original-Outgoing-Id: 639561623.810825-2434c72920fc0d27d1076b22344eea4c
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: Benjamin Kaduk <>
X-Mailer: Apple Mail (2.3608.
Archived-At: <>
Subject: Re: [Cbor] Benjamin Kaduk's No Objection on draft-ietf-cbor-tags-oid-06: (with COMMENT)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Concise Binary Object Representation \(CBOR\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 08 Apr 2021 08:00:31 -0000

Hi Ben,

> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> I made a PR at with an
> editorial suggestion (it ended up being just one -- well done!).

Merged, thank you.

> Is there anything useful to say about how bstrs tagged in this way will
> be (mis?)interpreted by implementations that don't understand these tag
> values?

I don’t think there is anything specific beyond what is true for all tagged byte strings.

> Section 2
>   Tag TBD110: tags a byte string as the [X.690] encoding of a relative
>   object identifier (also "relative OID").  Since the encoding of each
>   number is the same as for [RFC6256] Self-Delimiting Numeric Values
>   (SDNVs), this tag can also be used for tagging a byte string that
>   contains a sequence of zero or more SDNVs.
> I did not think that CBOR was prone to reusing tag values for types that
> are semantically different but happen to have the same binary encoding
> rules.  Should generic SDNVs get a dedicated tag?

Relative OIDs by their nature need context to interpret them.
The same kind of context could say that they are really SDNV sequences outside the OID mechanism.
Saying “this is an SDNV sequence but I won’t tell you how to use it” isn’t particularly useful.
New tags could be allocated when specific non-OID SDNV usage patterns emerge.

> Section 7.1
> Please note which range (and encoded length?) the allocations should
> come from.  Alternately, mentioning specific requested values here might
> be wise (given that there are examples that assume specific values).

The request follows the pattern we have emerged of calling unassigned but suggested values TBD4711.  Examples of course may need to bind to specific values, which is where we used the suggested values.

Made the range explicit, a7b222f.

> Section 8
> We might mention something about how when tag factoring is in use you
> have to be careful that the only bstrs being affected do contain OIDs,
> and inadvertently tagging a compound structure that sometimes contains
> non-OID bstrs (in the relevant places) can have unexpected effects.

Added (9782c6e):

An attacker might trick an application into using a byte string inside
a tag-factored data item, where the byte string is not actually
intended to fall under one of the tags defined here.  This may cause
the application to emit data with semantics different from what was
intended.  Applications therefore need to be restrictive with respect
to what data items they apply tag factoring to.

> Section 9.1
> AFAICT RFC 6256 only needs to be normative because of the way the
> control operators are defined, and we rely on BER for everything else.

Yes.  Are you making this comment to state why this downref is relatively innocuous, or to say that we shouldn’t have the downref?

> (Also, it looks like BER has more strict requirements than SDNV for the
> minimal-length encoding, though I did not investigate this very
> thoroughly.)

Indeed.  However, this specification is more restrictive in not allowing leading zeroes except for an only byte.  E.g., Section 2.1 says:

>> Also, the first byte of each SDNV cannot be a
>> leading zero in SDNV's base-128 arithmetic, so it cannot take the
>> value 0x80 (bullet (c) in Section of {{X.690}}).

To make this clear from the outset, I changed in the terminology section (dd312ff) :

-The term "SDNV" (Self-Delimiting Numeric Value) is used as defined in {{-sdnv}}.
+The term "SDNV" (Self-Delimiting Numeric Value) is used as defined in
+{{-sdnv}}, with the additional restriction detailed in {{reqts}}.

Thank you!

Grüße, Carsten