Re: [COSE] Key identifier of type bstr / int

[Carsten Bormann <[e-mail]>]

On 21. Mar 2022, at 23:20, Michael Richardson <[e-mail]> wrote:
> 
>> kid => int / bstr
> 
> It's one of the features of CBOR, as a self-describing format, that we can
> introduce new ways to do things.

Indeed.

So this is obviously an extension.  Old implementations can’t use the new data items enabled by that extension.
New implementations don’t have problems with old data items, so we call this backwards compatible, but not forward compatible.
We didn’t identify this as an extension point, so the lack of forward compatibility is likely to be universal — if you use an integer kid, old systems overwhelmingly will not understand you.

Now, there is also API compatibility — can you upgrade the COSE library without upgrading the using application.

I’d like to ask those who are proposing kid => int / bytes: are the two kid name spaces disjoint (so you need an API extension, too), or is an integer kid just a way to express the same kid as was already possible to express using a byte string kid.  Another way to say the latter is that all kids are byte strings and the integer representation is just a compressed way to express such a byte string.  Obviously, the latter way to interpret kids is slightly less efficient, because there are now two ways to express certain kids.  But the change is also local, i.e. you can do it in your library without changing anything else.

If we go for the latter, we will want to make sure that in particular the integers -24..23 map to useful byte strings and v.v.  Note that there is no need to make these byte strings short; e.g., a decimal representation (‘-24’ to ‘-1’ and ‘0' to ’23’ in CBOR DN), or maybe an octal one (’50’ to ’77’ and ’00’ to ’27’) would work well.  We don’t even need to support integers outside -24..23.

Grüße, Carsten