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

[Göran Selander <[e-mail]>]

> I’d like to ask those who are proposing kid => int / bytes:  are the two kid name spaces disjoint

Yes. An integer kid is considered different from a byte string kid.


Just to be clear on the source. This proposal is based on a previous conclusion on the COSE mailing list considering different solutions:

Solution A.
kid => int / bytes

Solution B.
kid => bytes
kid2 => int / bytes

Solution C.
kid => bytes
kid2 => int

In this previous discussion (see first part of this thread [1]) there was a mild preference for A. We can revisit this now, but it is good if people participating in the discussion are aware of the arguments made previously.


Göran


[1] https://mailarchive.ietf.org/arch/msg/cose/q_6kay8Z_4Wr48TFBXZU2oGRqoE/




From: Carsten Bormann <[e-mail]>
Date: Tuesday, 22 March 2022 at 00:00
To: Michael Richardson <[e-mail]>
Cc: Laurence Lundblade <[e-mail]>, Orie Steele <[e-mail]>, Göran Selander <[e-mail]>, [e-mail] <[e-mail]>
Subject: Re: [COSE] Key identifier of type bstr / int
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