A range of tags for private use

[dynaxis]

I'm currently designing an inter-process method invocation system, where CBOR will be the main message encoding. I need to tag references to remote objects in the messages, but it seems silly to get a tag assigned in https://docs.google.com/spreadsheets/d/1UajnKeIx_piJsAGRz5YJprvfwrBUeSVykqwG_JQL9rk/edit?usp=sharing. Since the tag for object references will only be used in my system, it seems a waste of the tag code space if I try to register my tag in the IANA registry.

In the case like mine, I think it's a common practice to reserve a range of tag values for private use. I think I might write a spec and reserve a range of tag values from the registry, but it's better to have it specified in the main CBOR spec, IMHO.

What do you think?

[Pique7]

This question is obviously still unanswered for a few years, but I have the same problem now. What approach do you suggest to implement a custom CBOR data type for a rather small or internal project? Would it be necessary to register an official CBOR tag? Is there an alternative solution?

[cabo]

If you mainly want a tag number to be different from other tag numbers, just do a "FCFS" registration of a tag. That's essentially filling in one form at iana.org.

If there would be value in interoperating using this tag with other users, you'd probably want to provide a specification. Again, for minimal hassle, you can still do an "FCFS" registration that points to a specification somewhere on the web, preferably in a stable space (but that will not be checked for an FCFS registration).

[Pique7]

Thank you for the quick reply. I want to include DER encoded certificates and related data directly in a CBOR structure without format conversion. So essentially I need semantic tagging for byte strings. I don't know whether this could be relevant for other users.
I have never been involved with IANA registration processes. Also, I am not sure whether I have already understood the whole idea of CBOR tags.

[cabo]

You can represent a DER-encoded certificate in a byte string.
See for example RFC9360, which puts DER-encoded RFC 5280 ("X.509") certificates into a COSE header (a CBOR map structure).

Tags are useful here if you need to identify the byte strings as such and they are not otherwise identified. RFC 9360 uses map keys such as 32 (labeled "x5chain" in the document) instead to do this identification. (Actually, map key 32 in a COSE header means one byte string or an array of two or more byte strings, each containing a DER-encoded certificate.)