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, 02 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 >> >
- [Ace] Transporting different types of cnf objects… Jim Schaad
- Re: [Ace] Transporting different types of cnf obj… Ludwig Seitz
- Re: [Ace] Transporting different types of cnf obj… Jim Schaad
- Re: [Ace] Transporting different types of cnf obj… Cigdem Sengul
- Re: [Ace] Transporting different types of cnf obj… Cigdem Sengul
- Re: [Ace] Transporting different types of cnf obj… Carsten Bormann
- Re: [Ace] Transporting different types of cnf obj… Hannes Tschofenig
- Re: [Ace] Transporting different types of cnf obj… Cigdem Sengul
- Re: [Ace] Transporting different types of cnf obj… Hannes Tschofenig
- Re: [Ace] Transporting different types of cnf obj… Carsten Bormann