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

Ludwig Seitz <ludwig.seitz@ri.se> Tue, 04 June 2019 06:50 UTC

Return-Path: <ludwig.seitz@ri.se>
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 9B3D812006D for <ace@ietfa.amsl.com>; Mon, 3 Jun 2019 23:50:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=risecloud.onmicrosoft.com
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 0hWy-vCZaZ6D for <ace@ietfa.amsl.com>; Mon, 3 Jun 2019 23:50:41 -0700 (PDT)
Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00055.outbound.protection.outlook.com [40.107.0.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC3E512006A for <ace@ietf.org>; Mon, 3 Jun 2019 23:50:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=RISEcloud.onmicrosoft.com; s=selector2-RISEcloud-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=X1xt102O8o0FY60wXXmoGOiqwuQTFD9kwbTPBl1RwHE=; b=DT+Io09Cd5Zo6RtF9fjOFEIqS/mkkZYcM8PpG8zeCU5jye9+v4ZkISznagrjAq9fIAijHf7vEcc02BRvIikZlSHo+0T0wGmVb9qL96K6I97W5g1vOxr2ihM7DUxp8CuGV0SVDZfLI5j0C/6Nk5xWfgqQ+pPQ+ElKXnOzfnB4Apw=
Received: from DB6P18901CA0013.EURP189.PROD.OUTLOOK.COM (2603:10a6:4:16::23) by DB6P189MB0328.EURP189.PROD.OUTLOOK.COM (2603:10a6:6:3c::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1943.22; Tue, 4 Jun 2019 06:50:38 +0000
Received: from AM5EUR02FT050.eop-EUR02.prod.protection.outlook.com (2a01:111:f400:7e1e::207) by DB6P18901CA0013.outlook.office365.com (2603:10a6:4:16::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1943.18 via Frontend Transport; Tue, 4 Jun 2019 06:50:37 +0000
Authentication-Results: spf=pass (sender IP is 194.218.146.197) smtp.mailfrom=ri.se; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=ri.se;
Received-SPF: Pass (protection.outlook.com: domain of ri.se designates 194.218.146.197 as permitted sender) receiver=protection.outlook.com; client-ip=194.218.146.197; helo=mail.ri.se;
Received: from mail.ri.se (194.218.146.197) by AM5EUR02FT050.mail.protection.outlook.com (10.152.9.252) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.20.1943.19 via Frontend Transport; Tue, 4 Jun 2019 06:50:37 +0000
Received: from [10.112.134.122] (10.100.0.158) by sp-mail-2.sp.se (10.100.0.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Tue, 4 Jun 2019 08:50:37 +0200
To: <ace@ietf.org>
References: <000201d51814$34a85fc0$9df91f40$@augustcellars.com>
From: Ludwig Seitz <ludwig.seitz@ri.se>
Message-ID: <9a0bbcd4-6055-729c-7ca8-205d0a1fd681@ri.se>
Date: Tue, 4 Jun 2019 08:50:36 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0
MIME-Version: 1.0
In-Reply-To: <000201d51814$34a85fc0$9df91f40$@augustcellars.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms000509070506050103090305"
X-Originating-IP: [10.100.0.158]
X-ClientProxiedBy: sp-mail-1.sp.se (10.100.0.161) To sp-mail-2.sp.se (10.100.0.162)
X-EOPAttributedMessage: 0
X-Forefront-Antispam-Report: CIP:194.218.146.197; IPV:NLI; CTRY:SE; EFV:NLI; SFV:NSPM; SFS:(10009020)(136003)(396003)(376002)(346002)(39860400002)(2980300002)(189003)(199004)(5660300002)(235185007)(44832011)(3846002)(53546011)(76176011)(65806001)(486006)(6116002)(126002)(53936002)(11346002)(65956001)(6916009)(33964004)(86362001)(356004)(71190400001)(2351001)(70586007)(70206006)(74482002)(5024004)(31696002)(14444005)(305945005)(65826007)(229853002)(68736007)(7736002)(77096007)(64126003)(26005)(22746008)(386003)(16526019)(186003)(69596002)(16576012)(316002)(16586007)(446003)(476003)(2616005)(40036005)(8936002)(106002)(81166006)(81156014)(8676002)(568964002)(2906002)(478600001)(31686004)(336012)(84326002)(36756003)(58126008)(22756006)(6246003); DIR:OUT; SFP:1101; SCL:1; SRVR:DB6P189MB0328; H:mail.ri.se; FPR:; SPF:Pass; LANG:en; PTR:InfoDomainNonexistent; MX:1; A:1;
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 006b194e-d784-48ed-97f3-08d6e8b8f377
X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600148)(711020)(4605104)(4709080)(1401327)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:DB6P189MB0328;
X-MS-TrafficTypeDiagnostic: DB6P189MB0328:
X-Microsoft-Antispam-PRVS: <DB6P189MB0328863A4D769ED376DAA06A82150@DB6P189MB0328.EURP189.PROD.OUTLOOK.COM>
X-MS-Oob-TLC-OOBClassifiers: OLM:10000;
X-Forefront-PRVS: 0058ABBBC7
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam-Message-Info: xbuZV0OekssKUKqA94CtV5P3s0+dgO80dqdHiWs7w0H+uTkWP6rD9GAy47AE+ksd+8a0/CSCma4QJP9V4GPJlVg5Af9pRF9TUa4K65KHzh0dyR0gg6phkEO1Ykdg/vkNW8vZJDhRqKZ/1SaWsJZqGojIGCljJrPWKzBwjagkxtBxvoFm7AgrouvkfQzk6H4XssI5wUzh77h8gGmweQZHUOStoY50wii5WwZgd07S94BLTLFkRL9yWumYdbbHVn/mvKpp3s/ZwWogIZe3Ldh1Jkf1dReAojYQumuWvYxwMO6pvi6FdA7sYvpzUR8rIEPPlQybxpeyFyzAP2xLUSjXsbZaKO8pRvNHZURl17X7kTRzK/Kv99rR451+EhMWoz3pKOnD9PJ1k9Xlgpc8PlEdkNaiYPkOan0TSD4ZnEjRiQw=
X-OriginatorOrg: ri.se
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Jun 2019 06:50:37.5191 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 006b194e-d784-48ed-97f3-08d6e8b8f377
X-MS-Exchange-CrossTenant-Id: 5a9809cf-0bcb-413a-838a-09ecc40cc9e8
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=5a9809cf-0bcb-413a-838a-09ecc40cc9e8; Ip=[194.218.146.197]; Helo=[mail.ri.se]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6P189MB0328
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/gWaa9sgFHYw-r8a6MNDRbPjiN-g>
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: Tue, 04 Jun 2019 06:50:45 -0000

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?

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

> 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