IETF Logo Mail Archive

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

Michael Richardson <mcr+ietf@sandelman.ca> Mon, 21 March 2022 22:20 UTC

Return-Path: <mcr@sandelman.ca>
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 6E8A13A1B87 for <cose@ietfa.amsl.com>; Mon, 21 Mar 2022 15:20:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.909
X-Spam-Level:
X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 TqIDTqBo9-KK for <cose@ietfa.amsl.com>; Mon, 21 Mar 2022 15:20:38 -0700 (PDT)
Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A7B83A1BC4 for <cose@ietf.org>; Mon, 21 Mar 2022 15:20:37 -0700 (PDT)
Received: from dooku.sandelman.ca (unknown [IPv6:2001:67c:1232:144:6e88:14ff:fe34:93bc]) by relay.sandelman.ca (Postfix) with ESMTPS id 2650E1F458; Mon, 21 Mar 2022 22:20:35 +0000 (UTC)
Received: by dooku.sandelman.ca (Postfix, from userid 179) id E893B1A01C2; Mon, 21 Mar 2022 18:20:33 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Laurence Lundblade <lgl@island-resort.com>, Orie Steele <orie@transmute.industries>, =?utf-8?Q?G=C3=B6ran_Selander?= <goran.selander@ericsson.com>, "cose@ietf.org" <cose@ietf.org>
In-reply-to: <DC1C335A-629D-4E4F-97BD-B4CA3519EDC6@island-resort.com>
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>
Comments: In-reply-to Laurence Lundblade <lgl@island-resort.com> message dated "Mon, 21 Mar 2022 19:01:39 +0100."
X-Mailer: MH-E 8.6+git; nmh 1.7.1; GNU Emacs 26.3
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Mon, 21 Mar 2022 18:20:33 -0400
Message-ID: <641639.1647901233@dooku>
Archived-At: <https://mailarchive.ietf.org/arch/msg/cose/gztr1WhdzXT0LPRR7oLVbZI2qAw>
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 22:20:51 -0000

Laurence Lundblade <lgl@island-resort.com> 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

I don't think that this breaks *compatibility*
Old signed objects are still valid.

Things signed with a kid => int are incompatible with old implementations,
but so is "intkid => int", so there is no difference.  If you need to send
stuff to an old implementations (and the COSE ecosystem is very very young),
then can just stick to bstr format kids.

Old implementations can't process new things.  That's life.
Building things so that new features mean something to new implementations,
but are ignored by old implementations is called backwards compatibility.
But you can't have that anyway in this case.

It's one of the features of CBOR, as a self-describing format, that we can
introduce new ways to do things.

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-

v2.23.0 | Report a Bug | By Email