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

Toerless Eckert <tte@cs.fau.de> Thu, 22 July 2021 16:41 UTC

Return-Path: <eckert@i4.informatik.uni-erlangen.de>
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 188E23A07FB; Thu, 22 Jul 2021 09:41:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.887
X-Spam-Level:
X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, 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 NKaTAcyVu-i9; Thu, 22 Jul 2021 09:41:18 -0700 (PDT)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 424E03A07F6; Thu, 22 Jul 2021 09:41:12 -0700 (PDT)
Received: from faui48e.informatik.uni-erlangen.de (faui48e.informatik.uni-erlangen.de [131.188.34.51]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id BCC3754804C; Thu, 22 Jul 2021 18:41:05 +0200 (CEST)
Received: by faui48e.informatik.uni-erlangen.de (Postfix, from userid 10463) id B06694E7AFD; Thu, 22 Jul 2021 18:41:05 +0200 (CEST)
Date: Thu, 22 Jul 2021 18:41:05 +0200
From: Toerless Eckert <tte@cs.fau.de>
To: Carsten Bormann <cabo@tzi.org>
Cc: cose@ietf.org, "draft-ietf-anima-constrained-voucher@ietf.org" <draft-ietf-anima-constrained-voucher@ietf.org>, Esko Dijk <esko.dijk@iotconsultancy.nl>
Message-ID: <20210722164105.GC57276@faui48e.informatik.uni-erlangen.de>
References: <20210722160135.GB55573@faui48e.informatik.uni-erlangen.de> <DB7A84B4-29D1-4E2F-A821-1C78886C7866@tzi.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <DB7A84B4-29D1-4E2F-A821-1C78886C7866@tzi.org>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/cose/2Aa79IGYzDeZYGDyJZut7zMCYkA>
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 16:41:24 -0000

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 ?

-> 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.

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. But i guess the expectation in general is that
you wouldn't run into this situation in the targeted use-cases, and if you
do, yo'd have to put another envelope around the tokens with a new
registry (or mapping the CWT registry to that envelope).

> 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 ? Question for yet another WG (ACE) ? ;-))

Cheers
   Toerless

> Grüße, Carsten
> 
> [1]: https://www.iana.org/assignments/cwt/cwt.xhtml
> Scroll down to hcert

-- 
---
tte@cs.fau.de