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

Benjamin Kaduk <kaduk@mit.edu> Mon, 21 March 2022 18:19 UTC

Return-Path: <kaduk@mit.edu>
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 9F3C43A1A90 for <cose@ietfa.amsl.com>; Mon, 21 Mar 2022 11:19:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.907
X-Spam-Level:
X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01] 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 ydcsYIEAr_yz for <cose@ietfa.amsl.com>; Mon, 21 Mar 2022 11:18:59 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D231B3A1A8C for <cose@ietf.org>; Mon, 21 Mar 2022 11:18:58 -0700 (PDT)
Received: from mit.edu (c-73-169-244-254.hsd1.wa.comcast.net [73.169.244.254]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 22LIIm9r025052 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 21 Mar 2022 14:18:54 -0400
Date: Mon, 21 Mar 2022 11:18:47 -0700
From: Benjamin Kaduk <kaduk@mit.edu>
To: Laurence Lundblade <lgl@island-resort.com>
Cc: Orie Steele <orie@transmute.industries>, Göran Selander <goran.selander@ericsson.com>, "cose@ietf.org" <cose@ietf.org>
Message-ID: <20220321181847.GW13021@mit.edu>
References: <95B75634-B147-4756-A950-C6B139CF3ADD@ericsson.com> <9DF382AC-12A8-47A5-AAE7-2B0D75EAA669@island-resort.com> <EDFDB6E4-2BDE-4E2E-9CF0-D771E2DEF3C6@ericsson.com> <823C00C2-4F6C-4DF5-99B0-87D8524D4A9C@island-resort.com> <C059B669-4C5D-4980-A665-96A39F4457C3@island-resort.com> <AM4PR0701MB21958541C07CEA44DB1B1578F4169@AM4PR0701MB2195.eurprd07.prod.outlook.com> <CAN8C-_+3sWckZKo7KS2fsPU4pBHo+NNGgQpxg7p8LytFX01eEw@mail.gmail.com> <AM4PR0701MB2195D76D8CFCC873C1D05A04F4169@AM4PR0701MB2195.eurprd07.prod.outlook.com> <CAN8C-_K4EfFSar9H_QR+cV_pz+xhXtWA=pKK+rFv241E5DQofQ@mail.gmail.com> <DC1C335A-629D-4E4F-97BD-B4CA3519EDC6@island-resort.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <DC1C335A-629D-4E4F-97BD-B4CA3519EDC6@island-resort.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/cose/Z6J1ZScV_PzlLQ5tNdUMTDjR2IY>
Subject: Re: [COSE] 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: Mon, 21 Mar 2022 18:19:03 -0000

On Mon, Mar 21, 2022 at 07:01:39PM +0100, Laurence Lundblade wrote:
> Let me try to be more clear.
> 
> The COSE standard now is:
> 
>    kid => bstr
> 
> If we make this change:
> 
>    kid => int / bstr
> 
> then we break backwards compatibility for COSE as Mike pointed out today. So we need a separate parameter called kid2, ckid, intkid or such. 
> 
> To not break backwards compatibility we need:
> 
>    intkid = int
> 
> or:
> 
>    intkid = int / bstr
> 
> (I don’t remember why an int kid was needed, but do remember I was convinced that it was)

So, if you make it required that you have exactly one of 'kid' or 'intkid',
you need signaling to know which one to use.  If you have that signaling,
it's not a huge stretch to instead use the signaling for "okay, 'kid' can
be int now".  There may be gaps, like group communication scenarios (but
then you have to weaken "exactly one"), but it seems more interesting to
explore those gaps than to just say there is breakage if you switch 'kid'
to int.  There is breakage if you just start sending something new and
expecting people to understand it, too!

To reiterate: if you want to roll out *anything* new, you need to have a
deployment plan.  So let's compare what the deployment plans look like for
int 'kid' and 'intkid', rather than comparing apples to oranges.

(It is probably also worth thinking about "you have at most one of 'kid' or
'intkid' and how things degrade if something would have benefited from
'kid' but actually got an 'intkid' that it doesn't understand.)

-Ben