Re: [Cbor] Do we care about array-tags issue 6, clamped-uint8 arrays?

Sean Solberg <ssolbs99@gmail.com> Fri, 26 July 2019 14:25 UTC

Return-Path: <ssolbs99@gmail.com>
X-Original-To: cbor@ietfa.amsl.com
Delivered-To: cbor@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CF9312009C for <cbor@ietfa.amsl.com>; Fri, 26 Jul 2019 07:25:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.747
X-Spam-Level:
X-Spam-Status: No, score=-1.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 ZLd8VOLuTzBo for <cbor@ietfa.amsl.com>; Fri, 26 Jul 2019 07:25:26 -0700 (PDT)
Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com [IPv6:2a00:1450:4864:20::42b]) (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 97F1C12004A for <cbor@ietf.org>; Fri, 26 Jul 2019 07:25:26 -0700 (PDT)
Received: by mail-wr1-x42b.google.com with SMTP id f9so54614292wre.12 for <cbor@ietf.org>; Fri, 26 Jul 2019 07:25:26 -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; bh=g70KB5NXKdaKW1Od+1/8BX7/yDYNCTEsiPfETuRA0hc=; b=EJw1ts9GdeZFpv4TB6YY4QGO8iOPoMkhDA1NfOGzLusDlZ5Wg8ym4f3q9wrFVMeZRO YvX77b3zVpKS8FrXDKeAd0ZJhMmGi78KWaqsw0+vF8iSPz6+ByQ9mPofc93PmHx59lQQ GXXr8i+CFGthQQxXgQ/feMKqNo9k1IBL75kSL2kU6WmOR8VYeu2p84rfssNHMv+dlGqy eCdaTN/fLD9ebLSVx3j0cs6qp3AHXu0x4RBs95xdXBVUpoRetN9pL/JLt/xYX3WIrfiZ X11UzCNOUybepnx59jHiHXMZyip9aC4OjdalYPSRzXMlehsYk7gRkJgfq3GxQayQhaxf YkPA==
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; bh=g70KB5NXKdaKW1Od+1/8BX7/yDYNCTEsiPfETuRA0hc=; b=l+1xILZ6oijh28PndgIba0HDj0lnhu5/mNtMeficEpY1864qAqow08KozarUcy9WPe vTTXc4KlUsomUJFJnN9t23MS1MUCRPoCZx9ZUB/qGf8ks3GZJy97dc3qXCJz0Su9Svtz F2d9lC6v6o8/DICDyj/E0ld50zGTMzFA/Q2oEQTJKKeqOQsNilUzrUz4v9XykFU3TUAC l6xL5m3cLFqxIL7L9azFM4+muDSXJY5jFckQ7lI4UM88c0k4TLqiKinnOxFTwZZ3l7QR fzb5VXSnH5ZX/U4SUxI1mjd3kpZqv31VtXQBfBeBJ54nMmKkcDgVPTWUMYmMqG+2rU6a 8EzA==
X-Gm-Message-State: APjAAAX8+vJYnV8rDPF/ClwrefPY1YNS+i1JhrcsBiGNRbuG/U1Usvae CbksBEqviInA08/2lWSe0Y2LL6I0sSLT/s3IpKJI3Yhj
X-Google-Smtp-Source: APXvYqwTchydhmNw54biIU00eR8+GjK9ajkDXav+6/QoXM95M9UU4kAFuVdNZhRwMYwxATArqlrfLxCi1NDEEy8mazY=
X-Received: by 2002:adf:dcc6:: with SMTP id x6mr73659595wrm.322.1564151124805; Fri, 26 Jul 2019 07:25:24 -0700 (PDT)
MIME-Version: 1.0
References: <CANh-dXkkSJUOcHcBj1JRO20ULFVNNbu1GQU-j7bR7N-FCTt3HA@mail.gmail.com> <24038E27-C30B-47F4-91E8-68C02FCAE26D@tzi.org> <CANh-dXm0TLShk_9DT9fKq0CR4yJMr6=zntWL8fW2tB99o0Et3Q@mail.gmail.com> <3246C0B0-C5BF-4AC8-B99F-D9A44B780A2C@seantek.com> <DECE061A-328D-4B1B-BEB5-D73F5779B554@tzi.org> <1C432DAE-ABAA-4E02-84FB-57109563A86F@seantek.com> <CANh-dX===wNGksTGUEjireODnQHPmUJQUJ7XJh+U-4bGGjErfg@mail.gmail.com> <9F8F7DEB-54B1-4114-B211-9D8A1A685523@tzi.org>
In-Reply-To: <9F8F7DEB-54B1-4114-B211-9D8A1A685523@tzi.org>
From: Sean Solberg <ssolbs99@gmail.com>
Date: Fri, 26 Jul 2019 09:25:14 -0500
Message-ID: <CAAGYyXkcvtEFnhYu+2FcMMhsvrpZq-rOygcCJqhDG4xRCOMpbA@mail.gmail.com>
To: cbor@ietf.org
Content-Type: multipart/alternative; boundary="0000000000002b4c25058e96502f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/kMHuX1uFe0N6rIY467gEm26YuCc>
Subject: Re: [Cbor] Do we care about array-tags issue 6, clamped-uint8 arrays?
X-BeenThere: cbor@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Concise Binary Object Representation \(CBOR\)" <cbor.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cbor>, <mailto:cbor-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cbor/>
List-Post: <mailto:cbor@ietf.org>
List-Help: <mailto:cbor-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cbor>, <mailto:cbor-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 26 Jul 2019 14:25:28 -0000

Isn't the whole purpose of the tag mechanism there to provide a way for the
sender to tell the receiver more specifically what type the data actually
is?   IE) regular expression instead of just a string,  URI instead of just
a string,  Uint8ClampedArray instead of just a Uint8Array.    Even though
the concept of a Uint8ClampedArray is mostly a javaScript thing as most
other languages naturally are "clamping" bytes to the 0 to 255 range
(because of the definition of a byte), one of the golden rules I always to
try to follow is to preserve "type" as much as possible.

IMHO, the lack of good data typing is one of the reasons we have problems
with JSON.  Having mechanisms to explicitly communicate data type from
sender to receiver is one of the areas where CBOR shines.  Frankly, I don't
see it as any more of a security issue than any other data type tagging in
CBOR.  In all cases, all receivers should be coded to properly handle what
data types it needs to deal with and also properly handle any situation
where it receives a tag that it isn't coded to explicitly handle.

..Sean Solberg

On Thu, Jul 25, 2019 at 9:06 PM Carsten Bormann <cabo@tzi.org>; wrote:

> On Jul 25, 2019, at 16:36, Jeffrey Yasskin <jyasskin@google.com>; wrote:
> >
> > I remain
> > uncomfortable with having a serialization format describe behaviors
> > that the data had or should have when it was or is loaded into a
> > program.
>
> I don’t know how to avoid that.  If the input is an array, in most generic
> decoders I get an array to work from.  If the input is instead a map, I get
> a map (or a JavaScript object); that has quite different behavior.  So the
> supplier of the input already has a lot of control over the data structures
> that are input to my system.  Uint8ClampedArray just adds a slight twist to
> that as it might look too much like a Uint8Array.
> None of this relieves an application of validating its input — with a
> standard serialization format and a robust generic decoder, this can now
> simply be done on a higher level.
>
> Grüße, Carsten
>
> _______________________________________________
> CBOR mailing list
> CBOR@ietf.org
> https://www.ietf.org/mailman/listinfo/cbor
>