Re: [COSE] [Cose]: RFC8152(bis) question(s) (draft-ietf-anima-constrained-voucher)

Carsten Bormann <cabo@tzi.org> Thu, 22 July 2021 17:57 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 250003A0BC1; Thu, 22 Jul 2021 10:57:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 P8jKkUQROr0V; Thu, 22 Jul 2021 10:57:22 -0700 (PDT)
Received: from gabriel-smtp.zfn.uni-bremen.de (smtp.uni-bremen.de [134.102.50.15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 554C63A0BBC; Thu, 22 Jul 2021 10:57:22 -0700 (PDT)
Received: from smtpclient.apple (p548dcc89.dip0.t-ipconnect.de [84.141.204.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4GW0XJ2H5tz31LJ; Thu, 22 Jul 2021 19:57:20 +0200 (CEST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <20210722164105.GC57276@faui48e.informatik.uni-erlangen.de>
Date: Thu, 22 Jul 2021 19:57:19 +0200
Cc: "draft-ietf-anima-constrained-voucher@ietf.org" <draft-ietf-anima-constrained-voucher@ietf.org>, Esko Dijk <esko.dijk@iotconsultancy.nl>, cose@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <841B0A55-3021-4BA7-B128-342289BEB265@tzi.org>
References: <20210722160135.GB55573@faui48e.informatik.uni-erlangen.de> <DB7A84B4-29D1-4E2F-A821-1C78886C7866@tzi.org> <20210722164105.GC57276@faui48e.informatik.uni-erlangen.de>
To: Toerless Eckert <tte@cs.fau.de>
X-Mailer: Apple Mail (2.3654.120.0.1.13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/cose/KbMhFqZH45uk-vvlDF0q3jDr5vk>
Subject: Re: [COSE] [Cose]: RFC8152(bis) question(s) (draft-ietf-anima-constrained-voucher)
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: Thu, 22 Jul 2021 17:57:27 -0000

On 22. Jul 2021, at 18:41, Toerless Eckert <tte@cs.fau.de> wrote:
> 
> 
> On Thu, Jul 22, 2021 at 06:20:18PM +0200, Carsten Bormann wrote:
>> The European Digital Green Card (Covid pass) uses a CWT with claim -260.
>> Given that the claim -260 is registered in the CWT registry [1], there is no need to provide any other semantics with the signed object.
> 
> ?? Let me see if i correctly parsed the relevant info from the docs:
> 
> -> A CWT is a COSE object right ?

Yes, with an unprotected CWT claims set (UCCS) inside [1].

[1]: https://www.ietf.org/archive/id/draft-ietf-rats-uccs-01.html
(We are doing this the wrong way around…)

> -> RFC8392 does specify a Media Type application/cwt for it, so there IS
>   some level of semantic for the COSE payload expressed in the COSE object Media Type.
>   Except that the actual semantic of the cwt is in the CBOR claim key field.

That is not one field; the claim keys are map keys.

> If i understand it right, this would be an example i was looking for,
> and given the short name 'cwt' i couldn't find it, looking for 'cose' in the
> Media Type registry. I guess our work could equally have asked for a
> more hib abbreviation application/cbv (constrained brski voucher) ;-)
> 
> I am not so sure if demuxing the actual semantic by the claim key field
> alone would be sufficient when you had cases where you may needed to find
> a specific type CWT. Like when you had a drawer full of tokens, and you
> wanted to find the health certificate purely from the envelope without
> having to open up the COSE envelope and look into the claim key field of
> every token in the drawer.

That is not a good strategy, as any token you present is disclosing some information and you only want to disclose that to someone that your overseeing principal authorizes to receive it.  So you better have a better grip on the tokens that you can hand out.

>> If you do not use a CWT, you may want some other form of identification of what the payload is about, and the COSE content-type header parameter (3) is one of them.
> 
> Right. So why did RFC8392 not use the COSE content type field but
> invented its own claim key field ?

CWT for COSE what JWT is for JOSE.
No invention at all.

Grüße, Carsten