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

Jim Schaad <ietf@augustcellars.com> Sat, 01 June 2019 00:52 UTC

Return-Path: <ietf@augustcellars.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 E3FBB120128 for <ace@ietfa.amsl.com>; Fri, 31 May 2019 17:52:03 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 hyKpxkThoMd8 for <ace@ietfa.amsl.com>; Fri, 31 May 2019 17:52:02 -0700 (PDT)
Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 258F212011C for <ace@ietf.org>; Fri, 31 May 2019 17:52:02 -0700 (PDT)
Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 31 May 2019 17:51:55 -0700
From: Jim Schaad <ietf@augustcellars.com>
To: 'Ludwig Seitz' <ludwig.seitz@ri.se>
CC: <ace@ietf.org>
Date: Fri, 31 May 2019 17:51:50 -0700
Message-ID: <000201d51814$34a85fc0$9df91f40$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AdUWXkqDC0svTS0jSfCsrSxPhvL4Mg==
Content-Language: en-us
X-Originating-IP: [73.180.8.170]
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/QfsVTIxMRysCgiGhFiUlHAlwVpw>
Subject: [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: Sat, 01 Jun 2019 00:52:04 -0000

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.

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.

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