> On Mar 22, 2022, at 12:00 AM, Carsten Bormann <c...@tzi.org> wrote: > > 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.
From an API and implementation point of view, I like that int key IDs are just another way of putting the bytes on the wire. Seems like we could just say that single byte kid value 0x01 can be encoded as bstr h’01’ or as integer 01. Allow this only for single byte kids in a range. Implementations error out for integers that can’t map to a single byte kid. This keeps the COSE API, SW stack above and key databases the same, a byte string, no matter what encoding is used to convey. LL
_______________________________________________ COSE mailing list COSE@ietf.org https://www.ietf.org/mailman/listinfo/cose
