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

Carsten Bormann <cabo@tzi.org> Wed, 23 February 2022 08:55 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 348FA3A0E93; Wed, 23 Feb 2022 00:55:37 -0800 (PST)
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, 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 25PxyLHVwge9; Wed, 23 Feb 2022 00:55:34 -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 F29DD3A0E94; Wed, 23 Feb 2022 00:55:30 -0800 (PST)
Received: from smtpclient.apple (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 4K3VHL4PsDzDD7F; Wed, 23 Feb 2022 09:55:26 +0100 (CET)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.60.0.1.1\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <d0be0144-3245-04c7-7de3-4dfb1b6ad77e@gmail.com>
Date: Wed, 23 Feb 2022 09:55:26 +0100
Cc: Laurence Lundblade <lgl@island-resort.com>, "rats@ietf.org" <rats@ietf.org>, "cose@ietf.org" <cose@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <FE9E2EE8-F394-4803-A5CF-14AD37BB329C@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> <92C7CF7C-ED23-41B3-AB32-8438C4C88C20@tzi.org> <14c8d106-3b4b-f973-94b8-018852ff4769@gmail.com> <8C2C6592-D5B9-430A-B878-E1009E9BCF22@tzi.org> <AB9F0C55-9C23-43F1-A83F-91D4159C888F@island-resort.com> <59939C29-5370-4385-AE61-A21ADDC0D194@tzi.org> <ED025590-3CA0-42B8-B50E-030D94FA88D6@island-resort.com> <d0be0144-3245-04c7-7de3-4dfb1b6ad77e@gmail.com>
To: Anders Rundgren <anders.rundgren.net@gmail.com>
X-Mailer: Apple Mail (2.3693.60.0.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/cose/OmPMQfUO1EXeE0WEyyPyyv9Ujm8>
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: Wed, 23 Feb 2022 08:55:38 -0000

On 23. Feb 2022, at 09:04, Anders Rundgren <anders.rundgren.net@gmail.com> wrote:
> 
> Hi Folks,
> 
> IMO, deterministic serialization makes no sense if decoders anyway are more or less obliged to cope with anything that smells like CBOR.

The wording you use here indicates that you don’t really have a technical point.

CBOR is a precisely defined format.
We don’t have a “smells like” property; we do have “well-formed”.
A generic decoder needs to handle well-formed CBOR.
That is not complicated.

(Deterministic serialization makes sense when you need deterministic serialization.
It is *not* about reducing work for the decoder.)

> As a comparison, JavaScript's JSON object offers zero serialization options (*). This enables users to concentrate on their application. The same goes for Google's Protocol Buffer.

And for many generic CBOR encoders.

Specifications that use CBOR but somehow restrict encodings for a data item to a subset can cause complexity in the encoder.
Don’t do that, then, unless you really *need* to do it.  (Please fix EAT; stop doing this.)
What you think is a little tweak simply ensures that you can’t use generic encoders; this is a big loss.

Deterministic serialization is such a subset, which does have specific use cases, and I would expect its use to be a decision that is made being conscious of the added complexity.

> There is obviously (IMO of course...), room for a comparable (but potentially better) solution for CBOR.  I would be interested to hear how YOU would design such a thing.

It’s called STD94, and it is already done.

I’ll ignore the comments about JSON — the details here are mind-boggling, which is why I-JSON was needed.
(In the mind of Douglas Crockford, JSON is a “format” only, and the mapping between artifacts that conform to the grammar and application concepts is left as an exercise to the reader.  This led to interesting different interpretations, which tend to get in the way of interoperability.  Hence I-JSON.)

Grüße, Carsten