[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
- [COSE] [Cose]: RFC8152(bis) question(s) (draft-ie… Toerless Eckert
- Re: [COSE] [Cose]: RFC8152(bis) question(s) (draf… Carsten Bormann
- Re: [COSE] [Cose]: RFC8152(bis) question(s) (draf… Toerless Eckert
- Re: [COSE] [Cose]: RFC8152(bis) question(s) (draf… Carsten Bormann