Subject: [Cbor] Review draft-bormann-cbor-tags-oid-07

From: Jim Schaad <[email-masked]>
Date: Fri, 3 Jul 2020 11:39:53 -0700

* Section 1 - There has been a recent argument on one of the mailing lists
about the question between the value of an encoding and the contents of the
value of the encoding.  I think that it needs to be highlighted that this is
referring to the V portion of TLV for BER.  "The contents of these
encodings..." is mostly likely going to cause somebody to have the same
problem.

* Section 1 - last sentence - What it is being referred to here?

* Section 2 - What is a "primary integer"?  Is this one that has not yet
gone to high school?

* Section 2.1 - I don't think it is the tag that is invalid, but rather the
value in the tag that is invalid.  The "tagged value"?  (Is this a
well-formed error?)

* You need to update references and text to the CBOR bis document.

* Section 5 - Does it make any sense to allow the tags to be specified in a
nested manner?  TBD110(X) [TBD111(Y)] ?

* Section 5 - One way to handle the problem would be to define a new tag
which cancels any tag inheritance as a general purpose thing.  This might
also be useful for other tags which might be defined in this way in the
future.

* Section 7 - I would agree that having an operator that parses string
dotted format does not make any sense.  It might be useful to include the
.oid operator however which has the property of doing the magic.

* Section 7 - I need an example of .sdnv because I am having a problem
figuring out how it would be used.

* Section 7 - If we do nesting behavior on these tags, then a control
operator to make A relative to B would be useful as well.

Jim

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 4 Jul 2020 00:47:39 +0200

Hi Jim,

thank you for this flash override review :-)

> On 2020-07-03, at 20:39, Jim Schaad <[email-masked]> wrote:
> 

I added »(the "value" part of BER's
type-length-value structure)«.

> * Section 1 - last sentence - What it is being referred to here?

Last sentence:

It is intended as the reference document for the IANA registration of
the tags so defined.

It = this document?

Or did you mean the penultimate sentence?  That needed to be fixed; done.

> * Section 2 - What is a "primary integer"?  Is this one that has not yet

I have no idea.  ASN.1 term?  Ah right, X.660.  Since arcs can be identified both by its actual integer value and (not necessarily unambiguous) secondary identifiers, the integer value is called “primary” integer value.  Fixed this by adding explanation and getting rid of the “primary” elsewhere. 

> value in the tag that is invalid.  

Well, the value (tag content) is a byte string, and there are no validity requirements on byte strings.  It is that tag formed out of tag number and tag content that is invalid.

> The "tagged value"?  

We now call that “tag content” in 7049bis.

> (Is this a

No, a validity error.

> * You need to update references and text to the CBOR bis document.

Eventually…  But yes, using the terms from 7049bis helps. Fixed.

> nested manner?  TBD110(X) [TBD111(Y)] ?

Not sure how that would work.
Can you give an example?

I was thinking about stacking tags to deepen their effect into arrays and maps, but haven’t quite figured that out either.

> also be useful for other tags which might be defined in this way in the

Yes, but if you generate an example, that becomes unwieldy as well (the neutralizer needs to be inserted in awkward places; the CDDL will be horrendous).
So instead of starting out with an infinitely deep effect that then needs to be stopped, I was thinking about one-deep plus a way to extend that.
But first we need a few good examples.

> .oid operator however which has the property of doing the magic.

Done.

> figuring out how it would be used.

If there is a .fooseq, there should be a .foo for exactly one foo.

RFC5050blockflags-encoded = bytes .sdnv block-flags
block-flags = uint .bits &(
Block-must-be-replicated-in-every-fragment:       0
Transmit-status-report-if-block-cant-be-processed:       1
Delete-bundle-if-block-cant-be-processed:       2
Last-block:       3
Discard-block-if-it-cant-be-processed:       4
Block-was-forwarded-without-being-processed:       5
Block-contains-an-EID-reference-field:       6
)

Well, yeah, any reasonable spec would just carry the uint.

> operator to make A relative to B would be useful as well.

Again, if you have an example for that, I’m all ears.

I pushed an update to https://github.com/cabo/cbor-oid/tree/cleanup; view formatted at https://raw.githack.com/cabo/cbor-oid/cleanup/draft-bormann-cbor-tags-oid.html — plaintext diff at

https://tools.ietf.org/rfcdiff?url1=draft-bormann-cbor-tags-oid-07.txt&url2=https://raw.githubusercontent.com/cabo/cbor-oid/cleanup/draft-bormann-cbor-tags-oid.txt

Grüße, Carsten

---

From: Jim Schaad <[email-masked]>
Date: Fri, 3 Jul 2020 18:53:34 -0700

> -----Original Message-----
> From: Carsten Bormann <[email-masked]>
> Sent: Friday, July 3, 2020 3:48 PM
> To: Jim Schaad <[email-masked]>
> Cc: [email-masked]; [email-masked]
> Subject: Re: Review draft-bormann-cbor-tags-oid-07
> 
> Hi Jim,
> 
> > * Section 1 - There has been a recent argument on one of the mailing
> > lists about the question between the value of an encoding and the
> > contents of the value of the encoding.  I think that it needs to be
> > highlighted that this is referring to the V portion of TLV for BER.
> > "The contents of these encodings..." is mostly likely going to cause
> > somebody to have the same problem.
> 
> It is intended as the reference document for the IANA registration of the tags so
> defined.
> 
> It = this document?
> 

I thought that this was true, but given the distance between "This document" and "It" it was not a sure thing.

> 
> > * Section 2 - What is a "primary integer"?  Is this one that has not
> > yet gone to high school?
> 
> I have no idea.  ASN.1 term?  Ah right, X.660.  Since arcs can be identified both
> by its actual integer value and (not necessarily unambiguous) secondary
> identifiers, the integer value is called “primary” integer value.  Fixed this by
> adding explanation and getting rid of the “primary” elsewhere.

Ah yes - this would have been from 
{ joint-iso-itu-t country us      organization gov csor nistalgorithm hashalgs     sha256(1) }

Which is legal as long as the strings have been defined elsewhere.

> 
> > * Section 2.1 - I don't think it is the tag that is invalid, but
> > rather the value in the tag that is invalid.
> 
> Well, the value (tag content) is a byte string, and there are no validity
> requirements on byte strings.  It is that tag formed out of tag number and tag
> content that is invalid.
> 
> > The "tagged value"?
> 

I really need to try and memorize the new terminology.

> > * Section 5 - Does it make any sense to allow the tags to be specified
> > in a nested manner?  TBD110(X) [TBD111(Y)] ?
> 
> I was thinking about stacking tags to deepen their effect into arrays and maps,
> but haven’t quite figured that out either.

I managed to get my numbers backwards above - so that would probably make it harder to understand.   For short things it probably does not matter, but for longer things it might be useful.

tag(111) h'608680165030402' [  / 2.16.840.1.101.3.4.2
  tag(110) h'01',       / .1     sha256
 tag(110) h'02'         / .2     sha???  I would have to look it up, but it is one of the sha-2 hash functions.
]

An array of two hash functions which could be parsed into the two rooted OID values

> 
> > * Section 5 - One way to handle the problem would be to define a new
> > tag which cancels any tag inheritance as a general purpose thing.
> > This might also be useful for other tags which might be defined in
> > this way in the future.
> 
> Yes, but if you generate an example, that becomes unwieldy as well (the
> neutralizer needs to be inserted in awkward places; the CDDL will be
> horrendous).
> So instead of starting out with an infinitely deep effect that then needs to be
> stopped, I was thinking about one-deep plus a way to extend that.

Yeah, the CDDL would be just terrible to write.

> > dotted format does not make any sense.  It might be useful to include
> > the .oid operator however which has the property of doing the magic.
> 
> Done.
> 
> RFC5050blockflags-encoded = bytes .sdnv block-flags block-flags = uint .bits &(

Ok - I thought that I what you meant.  I just could not believe that was true.

> Again, if you have an example for that, I’m all ears.

root-sha2 = bytes .sdnvseq [ 60 840 1 101 3 4 2 ]
root-sha256 = byte .sdnvseq [ 60 840 1 101 3 4 2 1 ]
rel-sha25 = root-sha256 .oidrel root-sha2

> 
> I pushed an update to https://github.com/cabo/cbor-oid/tree/cleanup; view
> formatted at https://raw.githack.com/cabo/cbor-oid/cleanup/draft-bormann-
> cbor-tags-oid.html — plaintext diff at
> 
> https://tools.ietf.org/rfcdiff?url1=draft-bormann-cbor-tags-oid-
> 07.txt&url2=https://raw.githubusercontent.com/cabo/cbor-oid/cleanup/draft-
> bormann-cbor-tags-oid.txt
> 
> Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 4 Jul 2020 13:48:56 +0200

Hi Jim,

> An array of two hash functions which could be parsed into the two rooted OID values

Prefix compression is applicable to other data than OIDs (most prominently URIs).
I think we should handle that in a more generic way than specifically for OIDs.

(I had a short presentation at an IETF a couple of years ago about what I called “Tag 6 compression” because it had been around since about 2013 — I finally need to write this up.  It really works, and it is really low cost for a decoder...)

Grüße, Carsten

---

From: Sean Leonard <[email-masked]>
Date: Mon, 27 Jul 2020 07:11:47 -0700

> I have no idea.  ASN.1 term?  Ah right, X.660.  Since arcs can be identified both by its actual integer value and (not necessarily unambiguous) secondary identifiers, the integer value is called “p…

On this point specifically:

X.660 (2011) defines:

3.5.13 primary integer value: A primary value of type integer used to 
unambiguously identify an arc of the
international object identifier tree.
NOTE – An arc of the international object identifier tree has precisely 
one primary integer value, apart from long arcs, which
have only Unicode labels.

When I wrote the draft, I used that term specifically since it was 
defined in X.660. I think we should continue to use "primary integer 
value" as defined in X.660 but as Carsten said, I am okay with the term 
only being used once and thereafter referring to it as a simpler term.

To my knowledge, OIDs represented in X.660 string formats such as IRIs 
simply have not taken off for purposes of interchange, and when used in 
technical documentation, the {iso(1) identified-organization(3) ... } 
style (which is X.680, or X.660) or dotted-decimal OID style seem to 
predominate.

The most authoritative dotted-decimal OID style definition that I could 
find is in the LDAP specs, namely <numericoid> in RFC 4512. X.680 (2015) 
defines dotted-decimal style as well, see XMLObjectIdentifierValue 
(Section 32.3; see https://www.itu.int/rec/T-REC-X.680-201508-I/en), but 
the X.680 definition is unwieldy and allows for the names to appear in 
the identifiers as well.

-Sean

---

From: Sean Leonard <[email-masked]>
Date: Mon, 27 Jul 2020 07:43:43 -0700

> I think we should handle that in a more generic way than specifically for OIDs.

I control a very short OID arc, 1.3.179 {iso(1) 
identified-organization(3) penango(179)} and would be happy to donate a 
block of 16 one-byte identifiers for CBOR/CBOR working group (or IETF) 
use. The binary encoding of this prefix is h'2B8133'.

If I assign the block of 96-111 to CBOR (h'60' through h'6F'), then that 
yields four bytes, 2048 unique numbers that are just five bytes long and 
16 unique numbers that are four bytes long as a bonus. I could probably 
donate 32 one-byte identifiers without losing sleep over it.

OIDs are just a way to generate globally unique, language-agnostic 
identifiers. A unique identifier that is five bytes long is clearly 
superior to a web URI (which depends on perpetual domain name 
registration) or even a UUID (fixed 16 bytes long), and obviates any 
need for compression. I think the reason why OIDs get such a bad wrap is 
because they are unnecessarily long when politics are laid over them, 
like 1.3.6.1.4.1.9.9.179.1.3.3.1.13. If you want a short and globally 
unique one, you can't get better than OIDs.

Notably, I am not the only one to figure out how to get a short OID: 
looks like Amazon picked up #187 in 2015: 
<http://oid-info.com/get/1.3.187>. If you can convince anybody who has 
registered OIDs 1-127 to slice off a piece of their namespace, you can 
make them one byte shorter. And I just discovered that IANA itself has a 
registration under 1.3.90: <http://oid-info.com/get/1.3.90> which is 
h'2B5A'--just two bytes! I'm surprised that nobody has made use of it.

While there are a lot of approaches to prefix compression, this assures 
that you can use OIDs instead of other identifiers in CBOR for *globally 
unique* identifiers. It has another modern advantage in that 
www.oid-info.com is a publicly accessible wiki-style list of all the 
OIDs ever minted, so you can write a tool to retrieve the human-readable 
meaning of any OID with a simple HTTP GET request.

Sean