[COSE] Attempting to summarize: Key identifier of type bstr / int
Christian Amsüss <christian@amsuess.com> Wed, 23 March 2022 09:26 UTC
Return-Path: <christian@amsuess.com>
X-Original-To: cose@ietfa.amsl.com
Delivered-To: cose@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD3F53A0F04 for <cose@ietfa.amsl.com>; Wed, 23 Mar 2022 02:26:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9w1cthhtBCKE for <cose@ietfa.amsl.com>; Wed, 23 Mar 2022 02:26:42 -0700 (PDT)
Received: from smtp.akis.at (smtp.akis.at [IPv6:2a02:b18:500:a515::f455]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 911593A0C68 for <cose@ietf.org>; Wed, 23 Mar 2022 02:26:42 -0700 (PDT)
Received: from poseidon-mailhub.amsuess.com ([IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bd]) by smtp.akis.at (8.17.1/8.17.1) with ESMTPS id 22N9QahP068256 (version=TLSv1.2 cipher=ECDHE-ECDSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 23 Mar 2022 10:26:36 +0100 (CET) (envelope-from christian@amsuess.com)
X-Authentication-Warning: smtp.akis.at: Host [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bd] claimed to be poseidon-mailhub.amsuess.com
Received: from poseidon-mailbox.amsuess.com (poseidon-mailbox.amsuess.com [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bf]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 9359CD0; Wed, 23 Mar 2022 10:26:34 +0100 (CET)
Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a4d5:b3ce:1ea4:f0db]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 4BC8F71; Wed, 23 Mar 2022 10:26:34 +0100 (CET)
Received: (nullmailer pid 3327304 invoked by uid 1000); Wed, 23 Mar 2022 09:26:33 -0000
Date: Wed, 23 Mar 2022 10:26:33 +0100
From: Christian Amsüss <christian@amsuess.com>
To: "cose@ietf.org" <cose@ietf.org>
Cc: Laurence Lundblade <lgl@island-resort.com>, Carsten Bormann <cabo@tzi.org>, Michael Richardson <mcr+ietf@sandelman.ca>, Göran Selander <goran.selander@ericsson.com>, Orie Steele <orie@transmute.industries>
Message-ID: <YjrnyZpZ6tpiydvs@hephaistos.amsuess.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="s1zw5ygklc5D3yn8"
Content-Disposition: inline
In-Reply-To: <C059B669-4C5D-4980-A665-96A39F4457C3@island-resort.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/cose/DfjVY9esmo_ZMpjCrV7PEPj6bA0>
Subject: [COSE] Attempting to summarize: Key identifier of type bstr / int
X-BeenThere: cose@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: CBOR Object Signing and Encryption <cose.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cose>, <mailto:cose-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cose/>
List-Post: <mailto:cose@ietf.org>
List-Help: <mailto:cose-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cose>, <mailto:cose-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 23 Mar 2022 09:26:48 -0000
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 <lgl@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.com@dmarc.ietf.org <mailto:goran.selander=40ericsson.com@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+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 -- To use raw power is to make yourself infinitely vulnerable to greater powers. -- Bene Gesserit axiom
- [COSE] Key identifier of type bstr / int Göran Selander
- Re: [COSE] Key identifier of type bstr / int Laurence Lundblade
- Re: [COSE] Key identifier of type bstr / int Göran Selander
- Re: [COSE] Key identifier of type bstr / int Benjamin Kaduk
- Re: [COSE] Key identifier of type bstr / int Laurence Lundblade
- Re: [COSE] Key identifier of type bstr / int Göran Selander
- Re: [COSE] Key identifier of type bstr / int Laurence Lundblade
- Re: [COSE] Key identifier of type bstr / int Göran Selander
- Re: [COSE] Key identifier of type bstr / int Orie Steele
- Re: [COSE] Key identifier of type bstr / int Göran Selander
- Re: [COSE] Key identifier of type bstr / int Orie Steele
- Re: [COSE] Key identifier of type bstr / int Laurence Lundblade
- Re: [COSE] Key identifier of type bstr / int Orie Steele
- Re: [COSE] Key identifier of type bstr / int Göran Selander
- Re: [COSE] Key identifier of type bstr / int Orie Steele
- Re: [COSE] Key identifier of type bstr / int Benjamin Kaduk
- Re: [COSE] Key identifier of type bstr / int Anders Rundgren
- Re: [COSE] Key identifier of type bstr / int Mike Prorock
- Re: [COSE] Key identifier of type bstr / int Orie Steele
- Re: [COSE] Key identifier of type bstr / int Michael Richardson
- Re: [COSE] Key identifier of type bstr / int Carsten Bormann
- Re: [COSE] Key identifier of type bstr / int Anders Rundgren
- Re: [COSE] Key identifier of type bstr / int Laurence Lundblade
- Re: [COSE] Key identifier of type bstr / int Laurence Lundblade
- Re: [COSE] Key identifier of type bstr / int Göran Selander
- Re: [COSE] Key identifier of type bstr / int Orie Steele
- Re: [COSE] Key identifier of type bstr / int Anders Rundgren
- Re: [COSE] Key identifier of type bstr / int Carsten Bormann
- Re: [COSE] Key identifier of type bstr / int Laurence Lundblade
- Re: [COSE] Key identifier of type bstr / int Christian Amsüss
- [COSE] Attempting to summarize: Key identifier of… Christian Amsüss
- Re: [COSE] Key identifier of type bstr / int Ilari Liusvaara
- Re: [COSE] Key identifier of type bstr / int Tobias Looker
- Re: [COSE] Key identifier of type bstr / int Anders Rundgren
- [COSE] draft-looker-cose-bls-key-representations Anders Rundgren
- Re: [COSE] Key identifier of type bstr / int Michael Richardson
- Re: [COSE] draft-looker-cose-bls-key-representati… Orie Steele
- Re: [COSE] draft-looker-cose-bls-key-representati… Anders Rundgren
- Re: [COSE] Key identifier of type bstr / int Michael Richardson
- Re: [COSE] Key identifier of type bstr / int Carsten Bormann
- Re: [COSE] Key identifier of type bstr / int Laurence Lundblade