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

I prefer A, and have appreciated learning the history of the issue... I
think the other proposals are not worth the cost.

OS

On Tue, Mar 22, 2022 at 3:42 AM Göran Selander <goran.selander=
40ericsson.com@dmarc.ietf.org> wrote:

> > 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 <cabo@tzi.org>
> *Date: *Tuesday, 22 March 2022 at 00:00
> *To: *Michael Richardson <mcr+ietf@sandelman.ca>
> *Cc: *Laurence Lundblade <lgl@island-resort.com>, Orie Steele
> <orie@transmute.industries>, Göran Selander <goran.selander@ericsson.com>,
> cose@ietf.org <cose@ietf.org>
> *Subject: *Re: [COSE] Key identifier of type bstr / int
>
> On 21. Mar 2022, at 23:20, Michael Richardson <mcr+ietf@sandelman.ca>
> 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
> _______________________________________________
> COSE mailing list
> COSE@ietf.org
> https://www.ietf.org/mailman/listinfo/cose
>

-- 
*ORIE STEELE*
Chief Technical Officer
www.transmute.industries

<https://www.transmute.industries>