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

Cigdem Sengul <cigdem.sengul@gmail.com> Wed, 02 October 2019 12:00 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 1F1E1120046 for <ace@ietfa.amsl.com>; Wed, 2 Oct 2019 05:00:47 -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 CjQamVW-CLGQ for <ace@ietfa.amsl.com>; Wed, 2 Oct 2019 05:00:44 -0700 (PDT)
Received: from mail-qt1-x844.google.com (mail-qt1-x844.google.com [IPv6:2607:f8b0:4864:20::844]) (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 61A8C12000F for <ace@ietf.org>; Wed, 2 Oct 2019 05:00:44 -0700 (PDT)
Received: by mail-qt1-x844.google.com with SMTP id l3so25940131qtr.4 for <ace@ietf.org>; Wed, 02 Oct 2019 05:00:44 -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=HauOcKmEoU3HDFol/eCUVXwQv8hh6njuVfvchM1ih64=; b=H/zh5R9cl0VYHQ244ey8mVr9lbHS5cm8RpwSf860xxpYVKLRS1wXvEOuA6fMoxoTNj dkcFrhkjPv5EtLwmzK4nvk3nB71apCBtD6Xs+U2ClxkAL3jYSErTUE0o7a/JieaTYDu3 D2g73pXuT3KtolN/gWdsytXvANEk3+ovUkldWhQbAWW8dwQbAP5JdUMzDFx6dAitmXZh nf0VZqMw3QqlXMLu3dnMwCtlQlf7abxPK+nwHXdc9J64FLwDhuR8TmuWxOcZ+Qn5+uTG Qv9cODonnnB1r/g7YQMMdhQ3HPpb5W++oUdP5N7dH4Wmsqeik3BAtj4GYzBQ/KVV/mfh Fpmw==
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=HauOcKmEoU3HDFol/eCUVXwQv8hh6njuVfvchM1ih64=; b=rZOKlMBt45UXVrhoPVWZWkQ80NAoj0SlK9f7fy/laF/34OBEKseK+S11ixSBtSCR9Q jIiXJ2wGEiQHWL0i6OltwCpirex+p5FT9TuQcQGn8+/af4fNtJXV4cqXSKLv4xLJyqRc faJPviZG5BzB/egoxC6RGSW9ROy5l7MkRyB2NQeVseltwj8RMnycXlvoWBE1+04wuJ4v /Am5LdLb9m7ypGsD1GEHfoWpQcISDpc2ow9znQ1ByWdbzYvMpSYav5NgpvYNdlvFOHuK hzLDgg7wTNcIxcLZWAicqW8J53eHkrfhKdoItySgm8gZNLfMzih9DfC88AP8nIqk3T8g kiug==
X-Gm-Message-State: APjAAAXqzX1lMMeAwO/WErnV9+gnioONAOW/Z+zWn2lbnccjBdv9Zyhk 43h8o6BiiVG/nacyIp+Z5o3CGzIxSpWXPT7VGBo=
X-Google-Smtp-Source: APXvYqzgS5OWLkay6TPAAfjZ2kuQCP1j8KnhVHchc68+cW6FUCv1qEfhXpS7bC9UCZ5CJT8DJETT7GyJEkp+uU5L8cA=
X-Received: by 2002:ac8:36b0:: with SMTP id a45mr3545459qtc.105.1570017642833; Wed, 02 Oct 2019 05:00:42 -0700 (PDT)
MIME-Version: 1.0
References: <000201d51814$34a85fc0$9df91f40$@augustcellars.com> <9a0bbcd4-6055-729c-7ca8-205d0a1fd681@ri.se> <010901d51b04$92788a10$b7699e30$@augustcellars.com> <CAA7SwCPunMN6S0xwVd0nCKx_zwdGbgj-UVPOa7hRq6gMv7WUAg@mail.gmail.com>
In-Reply-To: <CAA7SwCPunMN6S0xwVd0nCKx_zwdGbgj-UVPOa7hRq6gMv7WUAg@mail.gmail.com>
From: Cigdem Sengul <cigdem.sengul@gmail.com>
Date: Wed, 2 Oct 2019 13:00:31 +0100
Message-ID: <CAA7SwCO_jb8aFW+hX9sf6pxm07=LGZ2tLtwv6u92k11zyexVbw@mail.gmail.com>
To: Jim Schaad <ietf@augustcellars.com>
Cc: Ludwig Seitz <ludwig.seitz@ri.se>, ace@ietf.org
Content-Type: multipart/alternative; boundary="000000000000e47bd60593ec3766"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/3336VeJsgE7xKTPbPtt3jaVzm60>
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: Wed, 02 Oct 2019 12:00:47 -0000

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