IETF Logo Mail Archive

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

Laurence Lundblade <lgl@island-resort.com> Mon, 21 March 2022 13:14 UTC

Return-Path: <lgl@island-resort.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 9B2A33A19C5 for <cose@ietfa.amsl.com>; Mon, 21 Mar 2022 06:14:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.905
X-Spam-Level:
X-Spam-Status: No, score=-1.905 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable 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 N5qvEb7qS5Cy for <cose@ietfa.amsl.com>; Mon, 21 Mar 2022 06:13:59 -0700 (PDT)
Received: from p3plsmtpa07-04.prod.phx3.secureserver.net (p3plsmtpa07-04.prod.phx3.secureserver.net [173.201.192.233]) (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 D1E713A1A8D for <cose@ietf.org>; Mon, 21 Mar 2022 06:13:53 -0700 (PDT)
Received: from dhcp-809e.meeting.ietf.org ([31.133.128.158]) by :SMTPAUTH: with ESMTPSA id WHr4nhZXM80O8WHr5nHv4e; Mon, 21 Mar 2022 06:13:52 -0700
X-CMAE-Analysis: v=2.4 cv=fIz8YbWe c=1 sm=1 tr=0 ts=62387a10 a=evEcgHmhfWX9km1CD+uJ7A==:117 a=evEcgHmhfWX9km1CD+uJ7A==:17 a=K6EGIJCdAAAA:8 a=48vgC7mUAAAA:8 a=1ehfp3u_U2fFC5907FYA:9 a=QEXdDO2ut3YA:10 a=iup2on5jtUURsU2Y:21 a=_W_S_7VecoQA:10 a=L6pVIi0Kn1GYQfi8-iRI:22 a=w1C3t2QeGrPiZgrLijVG:22
X-SECURESERVER-ACCT: lgl@island-resort.com
From: Laurence Lundblade <lgl@island-resort.com>
Message-Id: <C059B669-4C5D-4980-A665-96A39F4457C3@island-resort.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_37C90DDD-A780-4E74-A2DF-D3A378344316"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\))
Date: Mon, 21 Mar 2022 14:13:50 +0100
In-Reply-To: <823C00C2-4F6C-4DF5-99B0-87D8524D4A9C@island-resort.com>
Cc: "cose@ietf.org" <cose@ietf.org>
To: =?utf-8?Q?G=C3=B6ran_Selander?= <goran.selander=40ericsson.com@dmarc.ietf.org>
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>
X-Mailer: Apple Mail (2.3608.120.23.2.1)
X-CMAE-Envelope: MS4xfEzTbr+H0tuJ3Bz57075dQpEZ26PiU5XQWGGW8rTlVoJRgcbNiP8ApIMm3iOVG9rjyvtQXluAtwXAUbK9txfKqOWFdSPK2CK99JT0CWQqaZ9f0OvjQ3i 8cb4a0ckcAYhBnpNewvt6i8KERv5K6dIo7lNbBiqdrKarWvN/G7yg8VzedulBNuUaLGtCxBY+M8VS2l5RQhvgXSxVYbRk2gIWiAGqFCTE5vN0UornhghSKYl XpHCrc72jyQoMxw3NhYpQK1eKaKsB9vTjtX+AQFa8h0=
Archived-At: <https://mailarchive.ietf.org/arch/msg/cose/KuFZ67zU4bCRikC2lKolcFxe3rE>
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 13:14:05 -0000

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

v2.8.7 | Report a Bug | By Email