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

Toerless Eckert <tte@cs.fau.de> Thu, 22 July 2021 16:01 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 5B7F83A4B80; Thu, 22 Jul 2021 09:01:48 -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, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=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 NLT61cmL0Elp; Thu, 22 Jul 2021 09:01:42 -0700 (PDT)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.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 99A023A4B77; Thu, 22 Jul 2021 09:01:42 -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 C0212548042; Thu, 22 Jul 2021 18:01:35 +0200 (CEST)
Received: by faui48e.informatik.uni-erlangen.de (Postfix, from userid 10463) id BA0404E7B00; Thu, 22 Jul 2021 18:01:35 +0200 (CEST)
Date: Thu, 22 Jul 2021 18:01:35 +0200
From: Toerless Eckert <tte@cs.fau.de>
To: cose@ietf.org
Cc: Carsten Bormann <cabo@tzi.org>, "draft-ietf-anima-constrained-voucher@ietf.org" <draft-ietf-anima-constrained-voucher@ietf.org>, Esko Dijk <esko.dijk@iotconsultancy.nl>
Message-ID: <20210722160135.GB55573@faui48e.informatik.uni-erlangen.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/cose/UTWlvCR9ciOMz8-hqqMX8yzVGqA>
Subject: [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:01:48 -0000

While following our anima hackathon for draft-ietf-anima-constrained-voucher,
i stumbled across not understanding some details. Maybe beside helping me
understanding in this thread, some of these questions might also be good
to be answered with better text in rfc8152bis.

My basic confusion is probably around the distinction between Syntax and Semantics.
rfc8152(bis) specifies a couple of Media Types and CBOR IDs to characterize 
the COSE blob and calls this the Semantic. But the only semantic that is
indicated by the items in Table 1/2 (cose-sign...cose-mac0) seems to be
the semantic of the cose-type, but not the semantic of the content.

Unfortunately, i don't know what outside of its use in our anima draft
example contant types would be. As far as i could find, none of the examples
in appendix C nor in https://github.com/cose-wg/Examples do have
the "content type" (3:) field with a value and none seem to elaborate
about different type of payloads.

In practice, we do need to indiate in the Media Type of a COSE blob
the semantic of the content and not only of the COSE "signing" semantics
This is why we are wanting to register a Media Type of
application/voucher-cose+cbor

Now if our approach of asking for sucha  media type to identify the cose content
semantic and not only the cose function semantic is the correct approach,
would i then not have o already find other media types for other ietf solutions
using cose ? I can not find any other Media Types in the IANA registry though..
Are there any ongoing that have not asked for early allocation yet ?

If my thinking is not correct, then it would be good to hear wha the
correct approach is to designate a media type to uses of cose.

Which brings me to the content type field. 

"Applications SHOULD provide this header parameter if the content structure is potentially ambiguous"

I would like to understand an example when the content structure is and 
when it is not ambiguous.

And of course, for the content type field, there is again the question
whether it should indicate only the syntax of the payload (CBOR) or
the semantic+syntax... And an answer of "COSE doesn't care, its up to
the user of COSE" is fine, but any such guidance would be helpfull
to have in rfc8152bis for adopters of COSE (such as us).

Thanks!
    Toerless