Re: [COSE] [IANA #1284212] expert review for draft-ietf-cose-cwt-claims-in-headers (cose)

Carsten Bormann <cabo@tzi.org> Sun, 05 November 2023 08:58 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 B58DBC1D46E4 for <cose@ietfa.amsl.com>; Sun, 5 Nov 2023 01:58:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 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] 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 KWc5XVPz9lOO for <cose@ietfa.amsl.com>; Sun, 5 Nov 2023 01:58:50 -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 E8EB2C2E0EAF for <cose@ietf.org>; Sun, 5 Nov 2023 01:58:48 -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 4SNT112hjxzDCc1; Sun, 5 Nov 2023 09:58:45 +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: <SJ0PR02MB7439EBC79259647E7BF45789B7ABA@SJ0PR02MB7439.namprd02.prod.outlook.com>
Date: Sun, 05 Nov 2023 09:58:34 +0100
Cc: "lgl island-resort.com" <lgl@island-resort.com>, Francesca Palombini <francesca.palombini@ericsson.com>, "drafts-expert-review-comment@iana.org" <drafts-expert-review-comment@iana.org>, "cose@ietf.org" <cose@ietf.org>, "paul.wouters@aiven.io" <paul.wouters@aiven.io>
Content-Transfer-Encoding: quoted-printable
Message-Id: <3E122426-7C91-4362-A5BF-C82D4417F482@tzi.org>
References: <RT-Ticket-1284212@icann.org> <rt-5.0.3-580051-1697567816-1595.1284212-9-0@icann.org> <rt-5.0.3-580636-1697568304-0.1284212-9-0@icann.org> <AS1PR07MB8616EFA12DB4F47075B7AB5198DDA@AS1PR07MB8616.eurprd07.prod.outlook.com> <MW4PR02MB7428022AEA2B4574410EE7EEB7DDA@MW4PR02MB7428.namprd02.prod.outlook.com> <AS1PR07MB8616E407B141D0C56F7EC65398DCA@AS1PR07MB8616.eurprd07.prod.outlook.com> <F465B3E6-B2CA-4580-B006-5DE7D8E9AABD@tzi.org> <MW4PR02MB7428E1B8942D1D64A825B0EEB7DCA@MW4PR02MB7428.namprd02.prod.outlook.com> <D4A1FC53-8D45-455B-8DF0-F3692F96AE4A@tzi.org> <MW4PR02MB7428A11CC4B4061109E5A07DB7DCA@MW4PR02MB7428.namprd02.prod.outlook.com> <56022A38-8D1A-4C65-A535-E3D45F3C3C7E@tzi.org> <MW4PR02MB7428751A6DC9804B8B15B66BB7DCA@MW4PR02MB7428.namprd02.prod.outlook.com> <641BD038-522A-41C2-B2C2-9E3C118DE915@tzi.org> <MW4PR02MB7428C73DA8A708AB8B860923B7DCA@MW4PR02MB7428.namprd02.prod.outlook.com> <4F61896C-4BAD-436E-AC31-3F50E9B93BF7@island-resort.com> <B7F75895-A2CD-4BDB-BDD9-08AE784690A2@tzi.org> <A5700329-C5E2-41B8-9AA8-9455855A088F@island-resort.com> <B2B317AD-CA0C-4B63-B797-572EF4D64E66@tzi.org> <SJ0PR02MB7439EBC79259647E7BF45789B7ABA@SJ0PR02MB7439.namprd02.prod.outlook.com>
To: Michael Jones <michael_b_jones@hotmail.com>
X-Mailer: Apple Mail (2.3774.200.91.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/cose/SMV_ygnuTpx52JtWAgBTnMPRyj0>
Subject: Re: [COSE] [IANA #1284212] expert review for draft-ietf-cose-cwt-claims-in-headers (cose)
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: Sun, 05 Nov 2023 08:58:53 -0000

On Nov 5, 2023, at 09:41, Michael Jones <michael_b_jones@hotmail.com> wrote:
> 
> Carsten, you asked " In all these cases, does the CWT added to the header form its own CWT that can be evaluated as such independently before jumping into the COSE object, or is it just intended to convey additional parameters to the processing intended for the COSE object with the other header parameters?"
> 
> To be clear, even normal CWTs (and JWTs) are simply bags of claims.  Their definitions express syntax - not fully-actionable semantics.  Profiles define semantics for the kinds of CWTs (or JWTs) that they define.  Cwt-claims-in-headers are the same.  They define syntax for where you can put claims.  It's up to profiles like lake-edhoc or SCITT to define how they're using those claims and what processing is associate with them.  Cwt-claims-in-headers doesn't change anything in that regard.

Hi Mike,

thank you for elucidating this so clearly.
You provide a description of JWTs and CWTs.

What I am interested in right now is using these as COSE header parameters.
In the COSE world, we try to be a bit more tied down on the semantics of the information in a COSE data item.
So you are motivating why using a CWT as a header parameter that is not further qualified as to its meaning in the COSE data item, should not be possible in COSE.

Together with an unambiguous “profile" identification, where the profile defines the semantics of any CCSes/CWTs included unambiguously, CWTs (or CCSes) do make sense in a COSE header.

Giving the header parameter carrying them a header parameter number that is specific to the usage (profile, if you want to call it this way) is one way to do this, and that is why I like the way EDHOC is using the kccs/kcwt header parameters.

Using a future “typ” parameter might supply semantics as well; to make a generic CCS/CWT header parameter useful we just would need to ensure that a “typ” is present and that this “typ" actually does define the semantics of a generic CCS/CWT header parameter (and possibly some restrictions on that parameter and where it may occur).  We could register a “typ” in conjunction with the generic CCS/CWT header parameter.

Grüße, Carsten