Hello everyone, attempting to summarize here:
* Ben and Michael made the argument[1][2] that older software will not recognize a kid2 just the same as it won't recognize a kid (and that either feature needs to be negotiated in a deployment plan). (Convincing Laurence[3] and Orie[4] who argued for a separate entry before). * There is the open question of semantics -- whether these two kinds of values inhabit a single semantic value space (i.e., the int are a compressed form of some string) or whether they inhabit a typed space where an integer is distinct from every byte string. Carsten posed on [5], with a concrete suggestion. AIU this is still open, with the trade-off being between API impact (a single value space can be transparently exposed by the old API), code point efficiency and possibly others. Discussion is still ongoing. Hoping I got all the latest points; I trust you complain loudly if you feel misrepresented. BR Christian [1]: https://mailarchive.ietf.org/arch/msg/cose/Z6J1ZScV_PzlLQ5tNdUMTDjR2IY/ [2]: https://mailarchive.ietf.org/arch/msg/cose/gztr1WhdzXT0LPRR7oLVbZI2qAw/ [3]: https://mailarchive.ietf.org/arch/msg/cose/0Gqhj3I1TqRyW_AprOs26PgC5bY/ [4]: https://mailarchive.ietf.org/arch/msg/cose/ozG-jYrFpcr1HrmGw9SNxAp3kuQ/ [5]: https://mailarchive.ietf.org/arch/msg/cose/1EXuPcjrGWSXNTk4rw2Ffp6Jpnk On Mon, Mar 21, 2022 at 02:13:50PM +0100, Laurence Lundblade wrote: > Thinking about Mike’s comment today in COSE/Vienna about backwards > compatibility. Looked at my code around this. That definitely seems like an > issue. > > What about defining “kid2” as just int? “kid” stays as bstr only. Then > there’s no backwards compatibility break. Adding support for another integer > parameter isn’t difficult. The downside is a little extra code to look at two > different parameters. > > You’d probably want to say that only one of the two kids MUST be present. > > Another random idea — could you say that it is allowed to translate an > integer kid to a bstr kid by assuming network byte order and stripping > leading zeros? > > LL > > > > > > On Aug 13, 2021, at 3:01 AM, Laurence Lundblade <l...@island-resort.com> > > wrote: > > > > Understood about the use case. Thx for the background. > > > >> On Aug 10, 2021, at 3:13 AM, Göran Selander > >> <goran.selander=40ericsson....@dmarc.ietf.org > >> <mailto:goran.selander=40ericsson....@dmarc.ietf.org>> wrote: > >> > >> Assume that we do want to allow key identifiers to be CBOR ints in certain > >> settings, what is the best (least intrusive) way to allow this while > >> still maintain compatibility with 'kid's supporting the type bstr? Another > >> alternative to what has been listed below is to define 'kid2' to only be > >> of type int - is that a better option? > > > > I didn’t write actual code to check, but they about the same to me. > > > > ‘kid' as int/bstr seems less confusing to me than ‘kid2’. It tells you it > > does exactly the same thing whether it is an int or a bstr. > > > > So my pick is ‘kid’, but ‘kid2’ is OK too. > > > > LL > > _______________________________________________ > COSE mailing list > COSE@ietf.org > https://www.ietf.org/mailman/listinfo/cose On Tue, Mar 22, 2022 at 12:00:24AM +0100, Carsten Bormann wrote: > On 21. Mar 2022, at 23:20, Michael Richardson <mcr+i...@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 -- To use raw power is to make yourself infinitely vulnerable to greater powers. -- Bene Gesserit axiom
signature.asc
Description: PGP signature
_______________________________________________ COSE mailing list COSE@ietf.org https://www.ietf.org/mailman/listinfo/cose
