IETF Logo Mail Archive

Re: [COSE] [Last-Call] [Iot-directorate] Iotdir telechat review of draft-ietf-cose-cwt-claims-in-headers-07

Carsten Bormann <cabo@tzi.org> Thu, 02 November 2023 22:40 UTC

Return-Path: <cabo@tzi.org>
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 6A1D1C151552; Thu, 2 Nov 2023 15:40:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.906
X-Spam-Level:
X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o-b2f_X6rdSX; Thu, 2 Nov 2023 15:40:55 -0700 (PDT)
Received: from smtp.zfn.uni-bremen.de (smtp.zfn.uni-bremen.de [IPv6:2001:638:708:32::21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C12DCC14CE55; Thu, 2 Nov 2023 15:40:54 -0700 (PDT)
Received: from smtpclient.apple (83-208-223-107.rcc.o2.cz [83.208.223.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4SLzP06xhfzDCcn; Thu, 2 Nov 2023 23:40:52 +0100 (CET)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.200.91.1.1\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <CAN8C-_KWuNXLROSesa-UoAntioHdfF6y=s9Gpnd0uZpo1HSO=g@mail.gmail.com>
Date: Thu, 02 Nov 2023 23:40:41 +0100
Cc: "lgl island-resort.com" <lgl@island-resort.com>, Henk Birkholz <henk.birkholz@sit.fraunhofer.de>, Hannes Tschofenig <hannes.tschofenig@gmx.net>, iot-directorate@ietf.org, cose <cose@ietf.org>, draft-ietf-cose-cwt-claims-in-headers.all@ietf.org, last-call@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <C4DF13BE-69AE-4FF7-B3B0-90B4BA2D85D5@tzi.org>
References: <169874540507.32382.14218122514486056121@ietfa.amsl.com> <83A3D56E-FDEA-46A3-ADB7-A5CA5130A1EB@island-resort.com> <82b9cb37-fb97-467b-b0d3-4752bf2f1076@gmx.net> <F3247BCE-E30B-4EA7-9652-AAE5CBB4637C@island-resort.com> <CAN8C-_LjTncbC6wz7+48A-z01AMyAexGXOvDsg5gL5qVoPoX7w@mail.gmail.com> <f350f06f-3819-4bfc-8c8b-687ab8dd908e@gmx.net> <2651c7c7-1062-f07c-0f9b-ef1650a8f026@sit.fraunhofer.de> <3B903BA4-68CA-4FB1-882A-9202B3E0C0A5@island-resort.com> <95BB52FB-4584-43D3-AD18-7F510639E03E@tzi.org> <CAN8C-_LiaPOX_e=K_xCcuaAK7aA3YgRtagyJoPVBwotsWWVPKw@mail.gmail.com> <F9D568F8-5FD2-4094-AE26-0198B76761CA@tzi.org> <CAN8C-_KWuNXLROSesa-UoAntioHdfF6y=s9Gpnd0uZpo1HSO=g@mail.gmail.com>
To: Orie Steele <orie@transmute.industries>
X-Mailer: Apple Mail (2.3774.200.91.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/cose/RkH3A5Y4HzG9JP9cNb0x3z5M6aY>
Subject: Re: [COSE] [Last-Call] [Iot-directorate] Iotdir telechat review of draft-ietf-cose-cwt-claims-in-headers-07
X-BeenThere: cose@ietf.org
X-Mailman-Version: 2.1.39
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: Thu, 02 Nov 2023 22:40:59 -0000

On Nov 2, 2023, at 23:29, Orie Steele <orie@transmute.industries> wrote:
> 
> typ in cose headers is a different draft, it's common in JOSE, and it's recommended in the JWT BCP... I suggest we assume it's not possible to specify the typ (media type) of the envelop in COSE, since that's true today.

Obviously we could register it with ccs/cwt.

> My point is that security assumptions are the same for both the protected header and the protected payload, as are the semantics for "claims", in the context of CWT... At least that's what the current draft says.

They are secured the same way.
That doesn’t mean what they say has the same semantics.
The cross-protocol issue I’m chasing after can exploit the undefinedness of the latter.

Grüße, Carsten

> I don't think this draft should say anything more.
> 
> OS
> 
> 
> 
> 
> On Thu, Nov 2, 2023, 5:11 PM Carsten Bormann <cabo@tzi.org> wrote:
> On Nov 2, 2023, at 23:02, Orie Steele <orie@transmute.industries> wrote:
> > 
> > I suggest we tackle these issues in a separate document.
> 
> I’m fine with that, as long as that document can make retroactive BCP14 statements :-) (*)
> 
> The CCS in the payload is entirely different from one in the header:
> The CCS in the payload is the focus of the signed/encrypted/mac'ed statement.
> The CCS/CWT in the header can only be supplementary information to what is in the payload.
> How does that supplementing affect the entire construct?
> Mike proposed using typ to supply this information.  But then it really needs to.
> 
> Grüße, Carsten
> 
> (*) OK, there is precedence in RFC 8725
> 
> -- 
> last-call mailing list
> last-call@ietf.org
> https://www.ietf.org/mailman/listinfo/last-call

v2.23.0 | Report a Bug | By Email