IETF Logo Mail Archive

Re: [COSE] [Rats] RAM requirements for COSE/CWT

Carsten Bormann <cabo@tzi.org> Tue, 22 February 2022 09:08 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: cose@ietfa.amsl.com
Delivered-To: cose@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8AB03A083B; Tue, 22 Feb 2022 01:08:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, 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 WV0h4EttV3aY; Tue, 22 Feb 2022 01:08:23 -0800 (PST)
Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [IPv6:2001:638:708:32::15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DE4C3A087E; Tue, 22 Feb 2022 01:08:21 -0800 (PST)
Received: from [192.168.217.118] (p5089ad4f.dip0.t-ipconnect.de [80.137.173.79]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4K2tcd5cdWzDCcq; Tue, 22 Feb 2022 10:08:17 +0100 (CET)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <2c8be442-9899-d117-155c-f6f2096b7055@gmail.com>
Date: Tue, 22 Feb 2022 10:08:17 +0100
Cc: Hannes Tschofenig <Hannes.Tschofenig@arm.com>, "rats@ietf.org" <rats@ietf.org>, "cose@ietf.org" <cose@ietf.org>
X-Mao-Original-Outgoing-Id: 667213697.316762-f5c032c77875eba569156a06b5c61ae9
Content-Transfer-Encoding: quoted-printable
Message-Id: <92C7CF7C-ED23-41B3-AB32-8438C4C88C20@tzi.org>
References: <e8995f0c-ad85-f702-da6b-051ffdc4cb08@gmail.com> <DBBPR08MB5915B874FD16107A7B0105AAFA3A9@DBBPR08MB5915.eurprd08.prod.outlook.com> <1a16c80d-40cd-baba-b1ce-2033dd0db294@gmail.com> <D22D0D63-F76C-48B3-A034-F8B5B2BB6005@tzi.org> <2c8be442-9899-d117-155c-f6f2096b7055@gmail.com>
To: Anders Rundgren <anders.rundgren.net@gmail.com>
X-Mailer: Apple Mail (2.3608.120.23.2.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/cose/DZVVZIjm0OhTyxN5Tnx5VCR6jCU>
Subject: Re: [COSE] [Rats] RAM requirements for COSE/CWT
X-BeenThere: cose@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: CBOR Object Signing and Encryption <cose.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cose>, <mailto:cose-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cose/>
List-Post: <mailto:cose@ietf.org>
List-Help: <mailto:cose-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cose>, <mailto:cose-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 22 Feb 2022 09:08:26 -0000

Hi Anders,

> On 2022-02-22, at 06:59, Anders Rundgren <anders.rundgren.net@gmail.com> wrote:
> 
> On 2022-02-21 17:31, Carsten Bormann wrote:
>> On 2022-02-21, at 17:15, Anders Rundgren <anders.rundgren.net@gmail.com> wrote:
>>> 
>>> I couldn't find any valid reason for using JSON
>> We seem to have found an area where we agree :-)
> 
> In this context, right :)
> However, due to the myriad of CBOR serialization options,

Not true.
All widely used serialization formats grant the encoder some freedoms in encoding information, CBOR is not different.  There are no “options” that need to be chosen or known to the recipient; there is only one CBOR.

> CWTs suffer from interoperability issues (*)

Not true.  Pure FUD.

> making JWTs a better choice for *ubiquitous* usage :(

No

> By *mandating* preferred serialization ("I-CBOR") you can achieve the same 
> interoperability as with JWTs,

Nonsense.  
JWTs don’t use deterministic encoding, and neither does CWT need to to.

> as well as getting away from the need to bury data-to-be-signed in byte-strings.

Detached payloads solve that particular problem (if you have it).
Note that “burying” in CBOR is a simple copy (or reference), while JOSE needs to base64-encoding everything, often in a nested way.

> Such solutions can also conserve buffer RAM in the case RAM is a scarce resource.  Yes, depending on the application your mileage may vary.

CBOR saves RAM compared to JSON here.

Grüße, Carsten

v2.8.7 | Report a Bug | By Email