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

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Wed, 07 Apr 2021 15:22:57 -0700

Benjamin Kaduk has entered the following ballot position for
draft-ietf-cbor-tags-oid-06: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-cbor-tags-oid/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I made a PR at https://github.com/cbor-wg/cbor-oid/pull/9 with an
editorial suggestion (it ended up being just one -- well done!).

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?

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?

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

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.

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

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 8 Apr 2021 10:00:24 +0200

Hi Ben,

Merged, thank you.

> be (mis?)interpreted by implementations that don't understand these tag

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

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

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

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

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

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

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 8 Apr 2021 15:49:00 -0700

Hi Carsten,

> New tags could be allocated when specific non-OID SDNV usage patterns emerge.

Okay, thanks for talking through it.

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

If I was holding the pen it wouldn't have the downref ... but it doesn't
actually matter.

> >> value 0x80 (bullet (c) in Section 8.1.2.4.2 of {{X.690}}).

Exactly, yes.

Thank you!

-Ben