Getting IANA Registration for some additional CBOR Tags

[ChristopherA]

Somewhat orthogonal to the CBOR representation issue #339, but related:

Blockchain Commons is also now encoding keys and other important cryptographic primitives natively and compactly using CBOR, and I hope to be sharing this proposal soon.

However, this one item in particular that @selfissued might be able to help with. At times we want to be able to include a CRC-32 tag for when the transport is less reliable, but optionally be able to exclude it when we know it is reliable. For instance, right we are using an encoded CBOR 25519 public key on .onion addresses for an TorV3 future DID method (see https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2020-006-urtypes.md for some of the CBOR type tags we are considering). Currently custom CBOR tags are the 3-byte range, making it a total of 5 bytes. However, if we could get this be one of the 1-byte reserved tags, it reduces the size for use by QR codes and other constrained transport purposes (mnemonics, etc.). However, adding to the reserved 1-byte CBOR tags are can only be added to with standards activities.

Are there other CBOR tags that we could propose to officially register at IANA that would make doing CBOR representations easier, more self-describable, and more compact?

-- Christopher Allen

[ChristopherA]

Here is a proposal for this CRC-32 tag.

https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2020-013-crc32-cbor-tag.md

cc @wolfmacnally

[selfissued]

FYI, I'm registering CBOR tags now in https://tools.ietf.org/html/draft-ietf-cbor-date-tag-05. This isn't hard to do. I can consult on draft(s) doing this.

[jonnycrunch]

@ChristopherA not clear what special tags need registering. If we can agree that when a DID has MIME type = did+cbor, we should assume that the namespace and value definitions are native CBOR and CBOR tag registries according to IANA. Then, if any new tags need registering then we do that with the CBOR working group and IANA tags without the burden of re-registering them in the did-spec-registry.

[msporny]

We need to be very careful with registering CBOR Tags, the small tag space is a finite space, we are a WG publishing specifications, we meet all the qualifications for going after the small tag namespace and that's a big problem if the group doesn't use common sense wrt. registering tags... we could exhaust the small tag namespace (especially wrt. where the registry is going -- lots of values in there).

[ChristopherA]

The only important one that requires "smallest tag space" I believe is CRC32, as it is used to offer integrity to lots of kinds of data (not just our purposes), needs to be small as it is for typically for compact use cases (like QRs and URI), but it also should be optional as often other layers do the data integrity. I believe that this will also be useful for other parties for use in CBOR related protocols and data models.

The other tags we'd like to see can be use the larger, more available spaces, especially if they are generally useful cryptographic primitives, but I'm hoping that we don't have to use the more openly available 3-byte spaces for all of them.

We have ad-hoc defined some CBOR tags in the 300s: https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2020-006-urtypes.md that we plan on using — some of which may be more generally useful by other protocols.

@selfissued your advice on best practices would be appreciated. /cc @wolfmcnally

-- Christopher Allen

[msporny]

While a CRC-32 CBOR Tag would be useful (in general), it's not clear how it would be useful in the DID Specification... use case isn't clear. I'm afraid that getting this issue addressed is going to be low priority until a use case is provided that impacts a variety of the implementers in the group.

To be clear, this isn't an argument against CBOR or CBOR Tags... it's a question wrt. what the "Additional CBOR Tags" are going to be (we need a definitive list) and how they're going to help.

At present, we have at least 4 different contemplated CBOR representations and none of them use a CRC32 value. Three of the four don't heavily use CBOR Tags (because it turns out that the CBOR Tags actually end up taking up quite a bit of space, especially if what you're attempting to do is encode to a QRCode.

This issue has to get more specific if we have a chance of directing the groups attention towards it.

[msporny]

We discussed this in the WG call today - there doesn't seem to be any interest from the rest of the group on this particular item (CRC32 CBOR Tag), especially without more details. This issue is on track to be closed without more specificity since there are other CBOR issues being tracked by the WG: CBOR .

[selfissued]

The IANA registration policy for CBOR tags for most ranges is Specification Required or First Come First Served - meaning that any specification can register tags. While if specific proposals are made to the working group, we can and should review them, actually registering the tags is dependent only only having concrete specifications for them, and not working group actions.

[wolfmcnally]

As it turns out we're not using this tag in the latest version of the UR spec/reference code, our need for it isn't pressing either, so I'm fine with closing this.

[msporny]

Thanks @wolfmcnally -- I have marked this particular issue as "pending close". It'll be closed in 7 days unless there are objections.

[brentzundel]

No comments since marked pending close, closing.