Re: [Ace] Transporting different types of cnf objects - CBOR vs JSON

Hannes Tschofenig <Hannes.Tschofenig@arm.com> Thu, 03 October 2019 10:42 UTC

Return-Path: <Hannes.Tschofenig@arm.com>
X-Original-To: ace@ietfa.amsl.com
Delivered-To: ace@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED4AB12011C for <ace@ietfa.amsl.com>; Thu, 3 Oct 2019 03:42:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=pSPv3Io/; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=armh.onmicrosoft.com header.b=Yug8caDN
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 MrjeJ7P245y0 for <ace@ietfa.amsl.com>; Thu, 3 Oct 2019 03:42:17 -0700 (PDT)
Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-eopbgr150051.outbound.protection.outlook.com [40.107.15.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D130612011A for <ace@ietf.org>; Thu, 3 Oct 2019 03:42:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=WIjAmqei2LsBJjjeSC/YMjaJw4LnQctwsrEmu1mjHvQ=; b=pSPv3Io/diNe6l7vxuCZ53LUDD3SpD6LCF4i5S97xSaNfTM6lZ3erAwBbE1cKb9J/P39f2h3oF0UKCMaMxKXvKNyzuHu4Du9ZblS71buGbhtQNW+3tL7MTqg/iO5BZykjLCARsOb6SS26Dv1sT1r1118+CdFh7aITqp9jFewblg=
Received: from VI1PR08CA0183.eurprd08.prod.outlook.com (2603:10a6:800:d2::13) by AM0PR08MB3329.eurprd08.prod.outlook.com (2603:10a6:208:57::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2305.17; Thu, 3 Oct 2019 10:42:12 +0000
Received: from VE1EUR03FT036.eop-EUR03.prod.protection.outlook.com (2a01:111:f400:7e09::205) by VI1PR08CA0183.outlook.office365.com (2603:10a6:800:d2::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.2305.15 via Frontend Transport; Thu, 3 Oct 2019 10:42:12 +0000
Authentication-Results: spf=fail (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; ietf.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;ietf.org; dmarc=none action=none header.from=arm.com;
Received-SPF: Fail (protection.outlook.com: domain of arm.com does not designate 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com;
Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by VE1EUR03FT036.mail.protection.outlook.com (10.152.19.204) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.2305.15 via Frontend Transport; Thu, 3 Oct 2019 10:42:12 +0000
Received: ("Tessian outbound 6481c7fa5a3c:v33"); Thu, 03 Oct 2019 10:42:09 +0000
X-CR-MTA-TID: 64aa7808
Received: from 6dd5d17de1ab.1 (ip-172-16-0-2.eu-west-1.compute.internal [104.47.12.57]) by 64aa7808-outbound-1.mta.getcheckrecipient.com id 40A83501-5A4D-43AF-9E01-C3C0FC09BA92.1; Thu, 03 Oct 2019 10:42:04 +0000
Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-db3eur04lp2057.outbound.protection.outlook.com [104.47.12.57]) by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 6dd5d17de1ab.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Thu, 03 Oct 2019 10:42:04 +0000
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=D4Mb+kUinyv/i4Fe2l+Hp2+ALBoA7RqhRYAxQf4yNPBGOz1gQ6wQSlAatyBn+Ufz62USXDD0w6lKCmXQM+SpdZjvHwPpikWITs8Bo5nFpK/4Aj8Ruoakby2Aft2RKVjvt4nV8snISctLiS+4NNOaqImmWDRKR3QYHvTdLL9SoNijyqhtZQJtSfEus77QNEEFcXC5gwp0cIYAkVsi0aBNaS8SygLGvD1rIRRhjNW7BvjFUUI8gda7OwMod/hmtrWbcUJQE22GLifh+Nut1dQsOparImaVOqP2+pBXmYMsudQkE10+wBPWg+O4wWy3nGcaEO5yOrfAC9vgyjQnrSbMnw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=9ntaVopMxAeGlRR/HrXrLrxYsRia77mM6GRPLy+B0AY=; b=Pw2T3HySUeq5K56+rLENESm6VW6d0ndnITcamc29pm/C1sBl+kgXWmXUjSx1dHhPsUUHWLOSFPk1rgmAolfPjiRujLoL7ahNbyegtUd6jaat0ucE+8CNGSKU7gQayeR8OsHWp0DejUf9sHyCfN9JcEumkOcaUEMfz4F60hrl1JB+5FMaUw2mQuZHu57STO53uh10iF0hplg2aR1lwsxp/yXSWvK3bOJq8w+xZzMBSj7KlQAb/Qy79lwryTLbvzl9hDl64GRofNBB+MRdubtseuWHrzGZ6xnfjCYkErGWRaUipg3F5+QxGvNT2l+B+PEd3hSaZdPlbnTiLDr6Qff1Hg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=9ntaVopMxAeGlRR/HrXrLrxYsRia77mM6GRPLy+B0AY=; b=Yug8caDNh00Olzt8eH8gUyRyAW7+ob0dvHrmSSbnfaGSD0teyLE6wNcp8T0vNV2aya9geJpflGDsK4pbTyYFWbFigmef7sxgO4TMiEg91A0/Ovt34XYZ4M0ImGhlumq2FCm5ObwSPIQViU7z8tTVgzoAC/0ymdq+1phy+qG5Wjo=
Received: from VI1PR08MB5360.eurprd08.prod.outlook.com (52.133.245.74) by VI1PR08MB2878.eurprd08.prod.outlook.com (10.170.236.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2305.23; Thu, 3 Oct 2019 10:42:02 +0000
Received: from VI1PR08MB5360.eurprd08.prod.outlook.com ([fe80::b003:8767:35c7:e31]) by VI1PR08MB5360.eurprd08.prod.outlook.com ([fe80::b003:8767:35c7:e31%2]) with mapi id 15.20.2305.023; Thu, 3 Oct 2019 10:42:02 +0000
From: Hannes Tschofenig <Hannes.Tschofenig@arm.com>
To: Cigdem Sengul <cigdem.sengul@gmail.com>
CC: Carsten Bormann <cabo@tzi.org>, Jim Schaad <ietf@augustcellars.com>, Ludwig Seitz <ludwig.seitz@ri.se>, "ace@ietf.org" <ace@ietf.org>
Thread-Topic: [Ace] Transporting different types of cnf objects - CBOR vs JSON
Thread-Index: AQHVeRkOjvoJjd1FkE+gdnIwpWcdiKdHUccAgAEmc4CAAEKUAIAAAM6w
Date: Thu, 03 Oct 2019 10:42:02 +0000
Message-ID: <VI1PR08MB5360351588B0569244A75FF3FA9F0@VI1PR08MB5360.eurprd08.prod.outlook.com>
References: <000201d51814$34a85fc0$9df91f40$@augustcellars.com> <9a0bbcd4-6055-729c-7ca8-205d0a1fd681@ri.se> <010901d51b04$92788a10$b7699e30$@augustcellars.com> <CAA7SwCPunMN6S0xwVd0nCKx_zwdGbgj-UVPOa7hRq6gMv7WUAg@mail.gmail.com> <CAA7SwCO_jb8aFW+hX9sf6pxm07=LGZ2tLtwv6u92k11zyexVbw@mail.gmail.com> <586CDF5F-F0E4-4514-8AB7-AAA383CA23FB@tzi.org> <VI1PR08MB5360B971D9424FA5AB652595FA9F0@VI1PR08MB5360.eurprd08.prod.outlook.com> <CAA7SwCOYW742y-C6XBhku2mNQ76QvsznqgNCX6kDUssJHTZoMg@mail.gmail.com>
In-Reply-To: <CAA7SwCOYW742y-C6XBhku2mNQ76QvsznqgNCX6kDUssJHTZoMg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ts-tracking-id: 7423d637-c7d1-4796-9368-6573aa646b8e.1
x-checkrecipientchecked: true
Authentication-Results-Original: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com;
x-originating-ip: [195.149.223.101]
x-ms-publictraffictype: Email
X-MS-Office365-Filtering-Correlation-Id: 76be5c67-5100-4760-8c7d-08d747ee59ac
X-MS-Office365-Filtering-HT: Tenant
X-MS-TrafficTypeDiagnostic: VI1PR08MB2878:|AM0PR08MB3329:
X-MS-Exchange-PUrlCount: 1
X-Microsoft-Antispam-PRVS: <AM0PR08MB33293E55EB82CDDA7E874162FA9F0@AM0PR08MB3329.eurprd08.prod.outlook.com>
x-checkrecipientrouted: true
x-ms-oob-tlc-oobclassifiers: OLM:10000;OLM:10000;
x-forefront-prvs: 01792087B6
X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009020)(4636009)(346002)(376002)(396003)(366004)(136003)(39860400002)(40434004)(189003)(199004)(40764003)(13464003)(53754006)(14444005)(7736002)(476003)(5024004)(6306002)(256004)(8676002)(81166006)(7696005)(6246003)(478600001)(8936002)(76176011)(966005)(102836004)(26005)(14454004)(4326008)(186003)(6506007)(53546011)(2906002)(54896002)(71200400001)(71190400001)(74316002)(81156014)(52536014)(6116002)(3846002)(790700001)(66066001)(316002)(86362001)(99286004)(6916009)(54906003)(606006)(64756008)(66476007)(33656002)(66946007)(6436002)(229853002)(5660300002)(25786009)(76116006)(66446008)(66556008)(9686003)(236005)(11346002)(446003)(486006)(55016002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR08MB2878; H:VI1PR08MB5360.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts)
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam-Untrusted: BCL:0;
X-Microsoft-Antispam-Message-Info-Original: sZxezc5MpmJ13AIwlqGaP3U0wi0IpX7aL+NOG+zxyJ1nIIh9fsIqzTYlx6ulqt4C40dmiFVxQg7mtZtRsuMFakYRFlt+HlyKwqd7jfxAht95SWE54ZdQZHrdN93QtMcf1kdDnkdwu6y6QXTCn+bPSd3zLwIh4Cf64cFInHVo83NY+MRsyv25Zc6JRKVmyJR6KIZTGr5QehSfVfonCttxykMRoTD8KonRq+nqt81cvVU4Akl+5aqQH0phn6uXLP99iAnjEIMnVi7QPZaVHtD7RQkeUPVhiRdT2yKijI1kBxxF5+f2pNVOSBo04hgB3IJicF/X5GnTzqF7qxKxc7l2/CLoZUJjDZvVKM2EkR0i6XnZ8bdHbCQe8Ie2oAuU88zX6VuhmjVI1qcykHcEfkDtAZR2oIETqwJs4ZhOEHkhxS2/gW1v/Pn1SDR3cdZe6+b7Op9jr2TUCZK5TsYZiiZ93A==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_VI1PR08MB5360351588B0569244A75FF3FA9F0VI1PR08MB5360eurp_"
MIME-Version: 1.0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR08MB2878
Original-Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com;
X-EOPAttributedMessage: 0
X-MS-Exchange-Transport-CrossTenantHeadersStripped: VE1EUR03FT036.eop-EUR03.prod.protection.outlook.com
X-Forefront-Antispam-Report: CIP:63.35.35.123; IPV:CAL; SCL:-1; CTRY:IE; EFV:NLI; SFV:NSPM; SFS:(10009020)(4636009)(39850400004)(396003)(376002)(346002)(136003)(1110001)(339900001)(189003)(199004)(40434004)(13464003)(53754006)(40764003)(2906002)(52536014)(336012)(7736002)(446003)(74316002)(11346002)(26005)(186003)(5660300002)(102836004)(790700001)(126002)(606006)(33964004)(99286004)(30864003)(486006)(476003)(71190400001)(53546011)(6506007)(6116002)(3846002)(6306002)(55016002)(14444005)(5024004)(6246003)(236005)(9686003)(6862004)(54896002)(4326008)(966005)(22756006)(14454004)(229853002)(356004)(316002)(54906003)(66066001)(26826003)(25786009)(478600001)(86362001)(81156014)(36906005)(76176011)(7696005)(81166006)(8676002)(8936002)(33656002)(70206006)(70586007)(76130400001)(16586007); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR08MB3329; H:64aa7808-outbound-1.mta.getcheckrecipient.com; FPR:; SPF:Fail; LANG:en; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; MX:1; A:1;
X-MS-Office365-Filtering-Correlation-Id-Prvs: 3a39b7a2-c5ac-4671-1ff8-08d747ee53a2
X-Forefront-PRVS: 01792087B6
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: lQYc68bGCdxypskqoxdzEMzMSDNP55aX5AI3kFJ8VLoUxEdbr6ofcGu7a6AawLH+JRJdPUMYpd5QVcWIWd843YR3g8DJ2bGDUO3Mo4zWrgE3a6lFX0HcoxdzXn7AD/8uSWQclt/mjSh/nJxB0mW0BqpakXvPgILTPirX9lNFGC5TNmCKS5Ui82wCsJT/T7JCeL7BGcvDhKrWfgVTvBkVHZf1RXkdgk9/sV5r2O2dkeIIvHZVu7kAOhwPYfUL++ifJJLV6PqmvBF6F0X4XngHJuk4D3/jvb0Gzmecl+PnGmLxiAhlz2bhR7EbEtuQaL28OhXMYOeoyOkEF0OfDpCwuBxzG7/DsTWabzoVgih2TQNfw9NiWZahMIVHUOFkGKx+sV+kgwo0eGN1flCjCwrUQUqGxU/LhpTaVn3RKmndEqABovWwZVVBq+v24GLO/XItKWRp5G+VSfRxkHe9599P/w==
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Oct 2019 10:42:12.7112 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 76be5c67-5100-4760-8c7d-08d747ee59ac
X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR08MB3329
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/g3Z6CsMcBiE3JhF8OOWxqqCS2OQ>
Subject: Re: [Ace] Transporting different types of cnf objects - CBOR vs JSON
X-BeenThere: ace@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" <ace.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ace>, <mailto:ace-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ace/>
List-Post: <mailto:ace@ietf.org>
List-Help: <mailto:ace-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ace>, <mailto:ace-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 03 Oct 2019 10:42:21 -0000

I believe the current approach is for the server to provide the symmetric key (rather than the client).

I have no idea when this topic gets resolved because folks keep changing their mind so quickly.

From: Cigdem Sengul <cigdem.sengul@gmail.com>
Sent: Donnerstag, 3. Oktober 2019 12:37
To: Hannes Tschofenig <Hannes.Tschofenig@arm.com>
Cc: Carsten Bormann <cabo@tzi.org>; Jim Schaad <ietf@augustcellars.com>; Ludwig Seitz <ludwig.seitz@ri.se>; ace@ietf.org
Subject: Re: [Ace] Transporting different types of cnf objects - CBOR vs JSON

Hello,

Thank you for your responses.

Until this issue is resolved, is it OK just to point to RFC 7800, which says the client provides the symmetric PoP key?

For MQTT draft,  would like to explain that C-RS is MQTT - MQTT may carry JSON/CBOR encoding for the Data fields in the packets.

C-AS and RS-AS can be HTTPS/CoAP/MQTT - what we describe in the draft it is HTTPS; MQTT support needs more thought for request-response style communication.
For HTTPS/CoAP, application/ace+json or application/ace+cbor content formats.

Since this info is a bit muddled in the current draft, I would like to ensure there is a clear paragraph, which the workgroup would be fine with.

Thank you for your help.
Sincerely,
--Cigdem





On Thu, Oct 3, 2019 at 7:42 AM Hannes Tschofenig <Hannes.Tschofenig@arm.com<mailto:Hannes.Tschofenig@arm.com>> wrote:
There is unfortunately a problem.

With proof-of-possession keys there is more than just conveying the CWT/JWT over another transport.
In the PK-case, the client has to provide the public key to the server and get it bound to the PoP token.
In the symmetric key case, the server has to provide the token along with the symmetric key that is also included although encrypted) in the PoP token.

We have standardized the transport of this additional information in ACE for use with CoAP but for HTTP we decided to do the work on OAuth, where it got stuck because the IoT-interested people are not there and the Web folks want something else.

Ciao
Hannes

-----Original Message-----
From: Ace <ace-bounces@ietf.org<mailto:ace-bounces@ietf.org>> On Behalf Of Carsten Bormann
Sent: Mittwoch, 2. Oktober 2019 15:05
To: Cigdem Sengul <cigdem.sengul@gmail.com<mailto:cigdem.sengul@gmail.com>>
Cc: Jim Schaad <ietf@augustcellars.com<mailto:ietf@augustcellars.com>>; Ludwig Seitz <ludwig.seitz@ri.se<mailto:ludwig.seitz@ri.se>>; ace@ietf.org<mailto:ace@ietf.org>
Subject: Re: [Ace] Transporting different types of cnf objects - CBOR vs JSON

There is no strong interdependency between Web transfer protocol (HTTPS/CoAPS) and data format.
COSE works great over HTTPS, and if it must be, you can ship JOSE over CoAPS.

Grüße, Carsten


> On Oct 2, 2019, at 14:00, Cigdem Sengul <cigdem.sengul@gmail.com<mailto:cigdem.sengul@gmail.com>> wrote:
>
> Hello all,
>
> I am trying to implement this discussion in the draft.  A point is raised about COSE keys in JSON messages.
> Could it be possible to go with:
> (1) HTTPS - application/ace+json - jwt - jose - PoP for JWT or
> (2) CoAP - application/ace+cbor - cwt - cose - PoP for CWT without
> mixing anything?
>
> (1) we thought to describe by default in the document, and (2) we said MAY be supported.
> Is there a problem with this approach?
>
> Thanks,
> --Cigdem
>
>
> On Tue, Jun 4, 2019 at 9:29 PM Cigdem Sengul <cigdem.sengul@gmail.com<mailto:cigdem.sengul@gmail.com>> wrote:
> Hello,
> Yes, we thought supporting JSON option would be good, though indeed there is no issue with transporting CBOR..
> If there are no other concerns, we can define the new media type in the MQTT draft.
> Will add the issue to GitHub repo.
>
> --Cigdem
>
> On Tue, Jun 4, 2019 at 7:37 PM Jim Schaad <ietf@augustcellars.com<mailto:ietf@augustcellars.com>> wrote:
>
>
> > -----Original Message-----
> > From: Ace <ace-bounces@ietf.org<mailto:ace-bounces@ietf.org>> On Behalf Of Ludwig Seitz
> > Sent: Monday, June 3, 2019 11:51 PM
> > To: ace@ietf.org<mailto:ace@ietf.org>
> > Subject: Re: [Ace] Transporting different types of cnf objects -
> > CBOR vs JSON
> >
> > On 01/06/2019 02:51, Jim Schaad wrote:
> > > Ludwig,
> > >
> > > I have been doing some adaptions of my codebase for dealing with
> > > the MQTT specification.  In the process of this, I have identified
> > > the following items that I think needs some discussion.  They may
> > > not need changes in any documents and maybe should get a new document.
> > >
> > > 1.  The MQTT document is using the content type "application/json"
> > > over HTTPS for transporting messages.  Does there need to be an
> > > "application/ace+json" defined as a media type, but not
> > > necessarily a CBOR media type?  I think the answer may be yes, but
> > > it could be a new
> > document.
> > >
> > I would argue that the first draft using such a media type would be
> > the right place to specify it. However I'm not sure using JSON is
> > the right approach for an ACE specification at all, aren't we
> > supposed to cater for the constrained world?
> > What is there to prevent us from transporting CBOR over HTTP?
>
> There would be no reason that one cannot transport CBOR over HTTP.  During the discussions for these drafts Hannes was very explicit that he wanted to be able to use JSON rather than CBOR with the protocol that was defined by ACE.  This would mean that there needs to be an ability to use JSON with the ACE framework document.
>
> I would have no problems with the statement that the MQTT document would be a good place to define the new media type.
>
> >
> > > 2.  If I use a "COSE_Key" confirmation method inside of an
> > > application/ace+json message, there is a potential problem and it
> > > could be dealt with in a number of different ways.
> > > *  The JWT confirmation method is identified as "jwk".  The COSE
> > > key must be translated into JOSE even if there is no equivalent
> > > key in JOSE.  I.e. that is a fatal error
> > > *  This does not make sense and the confirmation method should be
> > > changed to "cwk" so that either key format could be used in either
> > encoding.
> > >
> >
> > If we use JSON messages mixing in COSE becomes awkward. If the use
> > case calls for JSON, I'd argue it should also use RFC7800 instead of
> > draft-ietf-ace- cwt-proof-of-possession.
>
> I would not have a problem with this, it was one of the options above.  I was just expanding my code to allow for JSON to be used and ran into this.  I just wanted to get a clear group decision on this before I put things into stone.
>
> Jim
>
> >
> > > 3.  If the confirmation is changed, you would need to convert the
> > > COSE key to a binary string, base64 encoded it and pass as a
> > > string when occurring in a JSON encoding.  There is not any other
> > > valid way to do this (except see above of just converting the key
> > > format).  However, the opposite of putting a JOSE key into a COSE
> > > confirmation has three different options that could be used.
> > > *  Encode the JOSE key to a string and pass as a string
> > > *  Encode the JOSE key top level map as CBOR but leave all of the
> > > elements alone.
> > > *  Encode the JOSE key in CBOR including conversion of base64
> > > strings to binary data.
> > > (My first preference is probably the second option, but either of
> > > the first two make sense.)
> > >
> > > Jim
> > >
> >
> > I'm still unsure that there is a good use case for transporting JOSE
> > keys in CBOR, but if such a case turns up, I would agree that
> > touching the encoding as little as possible is a good idea (=option 1 or 2).
> >
> > /Ludwig
> >
> > --
> > Ludwig Seitz, PhD
> > Security Lab, RISE
> > Phone +46(0)70-349 92 51
>
>
> _______________________________________________
> Ace mailing list
> Ace@ietf.org<mailto:Ace@ietf.org>
> https://www.ietf.org/mailman/listinfo/ace
> _______________________________________________
> Ace mailing list
> Ace@ietf.org<mailto:Ace@ietf.org>
> https://www.ietf.org/mailman/listinfo/ace

_______________________________________________
Ace mailing list
Ace@ietf.org<mailto:Ace@ietf.org>
https://www.ietf.org/mailman/listinfo/ace
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.