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

[Carsten Bormann <[e-mail]>]

Hi Ben,

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

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