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

Cigdem Sengul <cigdem.sengul@gmail.com> Tue, 04 June 2019 20:29 UTC

Return-Path: <cigdem.sengul@gmail.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 493DC1202E9 for <ace@ietfa.amsl.com>; Tue, 4 Jun 2019 13:29:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 LjEWUUiewngX for <ace@ietfa.amsl.com>; Tue, 4 Jun 2019 13:29:55 -0700 (PDT)
Received: from mail-qt1-x836.google.com (mail-qt1-x836.google.com [IPv6:2607:f8b0:4864:20::836]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C64611200B6 for <ace@ietf.org>; Tue, 4 Jun 2019 13:29:54 -0700 (PDT)
Received: by mail-qt1-x836.google.com with SMTP id z19so15375502qtz.13 for <ace@ietf.org>; Tue, 04 Jun 2019 13:29:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=mZW/9MCBJbpQKLAg83WEWh51ZHOOHZUwnZ4j83clI5g=; b=l706mt7AQmo/3GMblxsxASCIhkVH7/0LSK8FdhIaMHXPugImfe+ncTzIYU/9sf73Zn QBdSfLsNqNGzPuJ0ClhUtL+ntp9R4ZIZ5QMa6aXj20RBc/waHWPip7qqWfoiWyWq8yvq 7GUAGRc2+kq6XSMlxeObmhGEoEa96FnJ6LJdFI3pONsB23SkXbA1H6f+KrwmDRcHDnKa kTZ6BXArTMzmfX4nCYirRaEJcEuBNChXl6b8VF0cyAYNhk16oPJ4Vt4ifo0rGzMEjhjB lNMhHkIboOli9XRd60drdQ3BmZpE+1TBhGj76K2WbqwIY8MBmKpi5ZUWGQE9sA0JfXuz c5Fw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=mZW/9MCBJbpQKLAg83WEWh51ZHOOHZUwnZ4j83clI5g=; b=QoutVvwE4TxeGGyPyIBXLY2z4S4cXD+t1Ynln2/6ErPWE+EDeJy52yRuvwVoL31qvm F5DC5XcJ7qbAoRNKGW+3jE21Yjf61QNAUJncU38ODMVEelK7ZygfIIAvhkhEq9kgNs4h dVzkZwbGgiXXfZJHou3iYgTelG4E1lYJSKtsIDzc/ktv1mdpZNEBHHapgd7mJJE8LfJC evU/M+9DLiR05B/9xcEZ9bj9n5jRddHApM3+2kjtb7PS4YTGOuOxJv9gPHGxmAM6zTTi tWZUVIGcKXqY6bSGDYfeBjm6my++cnKGcK9UkZCl++8irw1KajH103cLFuKAIqaW+W6s 8CQQ==
X-Gm-Message-State: APjAAAXv+mxilno8rnuN9SholZ3gz3k6Nz4+dW2+kB/ei2/If1PPiVIw vMXnd247RDC2vRExaSVHGZ8Dqfg/HXcW3y9RB1E=
X-Google-Smtp-Source: APXvYqyuMOXOu5LXroTUqoBxGvPzljSY+gNtMbRh3W2QdvofCLiDY4Z2GhpcbDr738ZCVMDWREz3Hx92LNtgVs2nRn0=
X-Received: by 2002:a0c:fd48:: with SMTP id j8mr28828850qvs.10.1559680193883; Tue, 04 Jun 2019 13:29:53 -0700 (PDT)
MIME-Version: 1.0
References: <000201d51814$34a85fc0$9df91f40$@augustcellars.com> <9a0bbcd4-6055-729c-7ca8-205d0a1fd681@ri.se> <010901d51b04$92788a10$b7699e30$@augustcellars.com>
In-Reply-To: <010901d51b04$92788a10$b7699e30$@augustcellars.com>
From: Cigdem Sengul <cigdem.sengul@gmail.com>
Date: Tue, 4 Jun 2019 21:29:42 +0100
Message-ID: <CAA7SwCPunMN6S0xwVd0nCKx_zwdGbgj-UVPOa7hRq6gMv7WUAg@mail.gmail.com>
To: Jim Schaad <ietf@augustcellars.com>
Cc: Ludwig Seitz <ludwig.seitz@ri.se>, ace@ietf.org
Content-Type: multipart/alternative; boundary="000000000000eb737c058a8557f3"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/SBhLVKnqXWImQ7MEsTbTZsyGLpw>
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 20:29:57 -0000

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>; wrote:

>
>
> > -----Original Message-----
> > From: Ace <ace-bounces@ietf.org>; On Behalf Of Ludwig Seitz
> > Sent: Monday, June 3, 2019 11:51 PM
> > To: 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
> https://www.ietf.org/mailman/listinfo/ace
>