[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