[Cbor] Validity checking

Laurence Lundblade <lgl@island-resort.com> Tue, 19 November 2019 13:11 UTC

Return-Path: <lgl@island-resort.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 EBF2B1208BB for <cbor@ietfa.amsl.com>; Tue, 19 Nov 2019 05:11:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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 wv2F57DjTWxK for <cbor@ietfa.amsl.com>; Tue, 19 Nov 2019 05:11:46 -0800 (PST)
Received: from p3plsmtpa09-09.prod.phx3.secureserver.net (p3plsmtpa09-09.prod.phx3.secureserver.net [173.201.193.238]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C115A12087E for <cbor@ietf.org>; Tue, 19 Nov 2019 05:11:46 -0800 (PST)
Received: from [172.16.134.137] ([101.100.166.3]) by :SMTPAUTH: with ESMTPA id X3IFiVvCdvE5rX3IGivJXz; Tue, 19 Nov 2019 06:11:45 -0700
From: Laurence Lundblade <lgl@island-resort.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Message-Id: <03E530C9-4B38-497A-BB4B-91488842C7F3@island-resort.com>
Date: Tue, 19 Nov 2019 21:11:42 +0800
To: cbor@ietf.org
X-Mailer: Apple Mail (2.3445.9.1)
X-CMAE-Envelope: MS4wfFp1/gdb4j50H9rZ9Svkvm27uvPBUzKUj7GDrQX7MEzG8c5iUrngv6ATqryZcS+Q7XlFa0QB9ftKY9yhdBDdXtLmbmcQOTw9wGf6pzvM/xac1JcRUgX/ 8/VSP/N9qDBY0a+lf0KZyaMs6dRBaGS8ctvwl75ELIvMf9On73BDxa/I
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/AoPJm1MxlhU-MrMGRHaS9Vnh8Dg>
Subject: [Cbor] Validity checking
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: Tue, 19 Nov 2019 13:11:48 -0000

I’m not sure if this should be filed as an issue or not, so I’ll put it in email first.

Here’s three classes of validity checks:

1) Easy
- Check whether the type of a tagged item is right, for example that tagged content of a tag 0 (string date) is a string
Checks in the class are easy and take no extra resources except a few lines of code. Any decoder author
Is likely to implement this check for tagged types they support because it is sort of the obvious thing to do.

2) Medium
- Check for duplicate keys in a map
Check in this class require writing a some special code and may use a lot of extra resources, particularly memory

3) Should not be done by a generic decoder (IMO)
- Check MIME structure
- Check unicode characters
- Check for valid base64
- Check for valid date string
It would be costly and inconvenient to do these in a generic CBOR decoder, but not at all for a MIME decoder, unicode renderer or base 64 decoder, so it makes almost no sense for a generic CBOR decoder to implement them. It would be waste of time and resources.


I don’t think it useful to talk of validity checking or not validity checking generic decoders as in the latest section 5.4. (IMO) only an insane decoder would check all validity as it would one that includes a MIME parser, base64 decoder and such. Many generic decoders will do no validity checking at all and be perfectly OK because they don’t decode tagged types and don’t do duplicate checking.

LL