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

Ilari Liusvaara <ilariliusvaara@welho.com> Wed, 23 March 2022 10:24 UTC

Return-Path: <ilariliusvaara@welho.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 DFF3A3A156C for <cose@ietfa.amsl.com>; Wed, 23 Mar 2022 03:24:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.91
X-Spam-Level:
X-Spam-Status: No, score=-6.91 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] 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 Cm-i18ZxA0mi for <cose@ietfa.amsl.com>; Wed, 23 Mar 2022 03:24:34 -0700 (PDT)
Received: from welho-filter2.welho.com (welho-filter2b.welho.com [83.102.41.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 504D03A152E for <cose@ietf.org>; Wed, 23 Mar 2022 03:24:32 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id 0232BD0070 for <cose@ietf.org>; Wed, 23 Mar 2022 12:24:30 +0200 (EET)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id orzdUnn4p5LH for <cose@ietf.org>; Wed, 23 Mar 2022 12:24:29 +0200 (EET)
Received: from LK-Perkele-VII2 (87-92-216-160.rev.dnainternet.fi [87.92.216.160]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id D09857A for <cose@ietf.org>; Wed, 23 Mar 2022 12:24:28 +0200 (EET)
Date: Wed, 23 Mar 2022 12:24:28 +0200
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: "cose@ietf.org" <cose@ietf.org>
Message-ID: <Yjr1XF5A2Cl2Jn1s@LK-Perkele-VII2.locald>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <C059B669-4C5D-4980-A665-96A39F4457C3@island-resort.com>
Sender: ilariliusvaara@welho.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/cose/UUABT3benpoBlBEEuNaL_T5CJpw>
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: Wed, 23 Mar 2022 10:24:38 -0000

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 does your code do if it encounters a recipient with int kid?

1. Treats the entiere message as malformed?
2. Ignores the recipient?
3. Something else? What?


And it is the implementations that do 1. (or 3. with some oddball
semantics) that worry me the most here. Not so much 2., as such
recipient is probably not correct anyway.



This also connects to the COSE-HPKE work: Where does one stick the
encapsulated ciphertext? It is naturally a bstr. It would seem natural
to stick it to the -1 (ephremeral key) field. Except that field is
defined to be a dictionary. However, this does not seem to stop editors'
copy from sticking a bstr to -1 field.



-Ilari