Re: [Cbor] Chunks with tags inside indefinite-length string (major type 2 and 3)

Jeffrey Yasskin <jyasskin@chromium.org> Thu, 05 December 2019 21:57 UTC

Return-Path: <jyasskin@google.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 636471200EF for <cbor@ietfa.amsl.com>; Thu, 5 Dec 2019 13:57:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.25
X-Spam-Level:
X-Spam-Status: No, score=-9.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org
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 3HB87THvR3tZ for <cbor@ietfa.amsl.com>; Thu, 5 Dec 2019 13:57:01 -0800 (PST)
Received: from mail-qt1-x831.google.com (mail-qt1-x831.google.com [IPv6:2607:f8b0:4864:20::831]) (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 58B4A120073 for <cbor@ietf.org>; Thu, 5 Dec 2019 13:57:01 -0800 (PST)
Received: by mail-qt1-x831.google.com with SMTP id 14so5070452qtf.5 for <cbor@ietf.org>; Thu, 05 Dec 2019 13:57:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Q7pLZygOy3QmL569/KN8Swdw7li+S6cDOCFjiW30Gc4=; b=O6Yke5XTAQLPhAA1eLt5clmNuSIOapzpeKHWzJ7XxNjqOhRzg/6PXwQ0/dUqJ/9b1b Ulld4TdhyiQoEa7BJ7c5qy9WGxB7exHgxj1g6gGbBn/IPAvgHdBgqdVDKOBHxOeRxjlO 1cmFWkJwUxgsz/dWah6aSswOLtpSm5y+Irelw=
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=Q7pLZygOy3QmL569/KN8Swdw7li+S6cDOCFjiW30Gc4=; b=TS8+NKP6zypP0FbJmOG2+OloNX3+i3xXW8xqs0Bb8FPd090vbkK8VpJALTS47QHNeF 6CjvUcTJSRyfuHsYabFRg9mljhnoYdABA8REHBJT+h8aPJA0FiKwZ4nijxvp06nlETce sLySiueEARYzC/9nKiLp4tJSZeOm8dp2mBpx4jHe+2MjeL8ur3VVg6t1WvVs3dBdvLTf 0LnzNoXvHrlZ8KA7myhRn7WiHIaPMD7XPQmXhzr83K8ckeoVe25D1g+lHUE4yVK36BNW dPMJ6UK1EJXUZEBqZH8/rhJcJsg3AV2blaaJyYi1dia1no/w3LuXtHhbAWhIEkDxLmSE auQg==
X-Gm-Message-State: APjAAAU7AbeAX1LEvCFT2E2+BUWKotViTyJE7xr1OX/EuCjWEErQob7R VyH4txIdzQpcf5psVD0t7W37LYkOIPsOYoIFhe2e8Q==
X-Google-Smtp-Source: APXvYqyNrXOISjryuaei3gc/zpWuRAC3E/6ueFGjiAPrgojS3s6YGVFuPx74i56sPWVUky66j6LpvfjYpmtX05d7xRQ=
X-Received: by 2002:ac8:488f:: with SMTP id i15mr8529130qtq.382.1575583019637; Thu, 05 Dec 2019 13:56:59 -0800 (PST)
MIME-Version: 1.0
References: <CA+qCGhv_d=uJxnPrnbRO_iN9nVhwPf0Qa8EvtqqXZS6pMaCyBw@mail.gmail.com> <CANh-dXnHnm2wxYPJfYJXmhHhOBJobnmFmwT5E=55PGcVv0ttPg@mail.gmail.com> <CA+qCGhtu5eZtmL+Xf+ZmgJ=NcfA0kV1zx+7_N7HY0eiM8DNHEw@mail.gmail.com>
In-Reply-To: <CA+qCGhtu5eZtmL+Xf+ZmgJ=NcfA0kV1zx+7_N7HY0eiM8DNHEw@mail.gmail.com>
From: Jeffrey Yasskin <jyasskin@chromium.org>
Date: Thu, 05 Dec 2019 13:56:47 -0800
Message-ID: <CANh-dXmX+D=DRLBG2HtE5cPSNv_W7Sqr094c4KzWtUtma3V0jg@mail.gmail.com>
To: Faye Amacker <faye.github@gmail.com>, cbor@ietf.org
Cc: Jeffrey Yasskin <jyasskin@chromium.org>
Content-Type: multipart/alternative; boundary="000000000000339eb90598fc0228"
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/NFp3pIZ7hKddGKF4kdfwT0ne34o>
Subject: Re: [Cbor] Chunks with tags inside indefinite-length string (major type 2 and 3)
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: Thu, 05 Dec 2019 21:57:03 -0000

I believe that's correct, with the caveat that protocols should be able to
specify that they accept a "number", which would accept primitive integers,
primitive floats, and tagged bigints, bigfloats, bigdecimals, and any new
tags defined to represent numbers.
https://cbor-wg.github.io/CBORbis/draft-ietf-cbor-7049bis.html#epochdatetimesect
has
some wording to restrict to just primitive integers.

Jeffrey

On Thu, Dec 5, 2019 at 1:47 PM Faye Amacker <faye.github@gmail.com> wrote:

> Jeffrey, I think you are correct.  It seems I misread a line in the
> pseudocode which made me doubt my interpretation of the text.
>
> Can you confirm that decoders (both generic and non-generic) should:
> * reject a tagged positive number if a protocol specifies a positive
> number.
> * reject a positive number if a protocol specifies a tagged positive
> number.
> * accept both positive number and tagged positive number only if the
> protocol specifies the specific tag is optional.
>
> Thanks again for your help.  I'm relieved tags on chunks are malformed.
>
> On Thu, Dec 5, 2019 at 1:18 PM Jeffrey Yasskin <jyasskin@chromium.org>
> wrote:
>
>> I *think*
>> https://cbor-wg.github.io/CBORbis/draft-ietf-cbor-7049bis.html#indefinite-length-byte-strings-and-text-strings is
>> pretty clear that the contained things have to have the same major type as
>> the indefinite-length string, and tags have a different major type. e.g. "a
>> series of zero or more byte or text strings" doesn't include the
>> possibility of tags, and "If any item between the indefinite-length string
>> indicator (0b010_11111 or 0b011_11111) and the “break” stop code is not a
>> definite-length string item of the same major type, the string is not
>> well-formed." says any other content is not well-formed.
>>
>> The pseudocode includes
>>
>> if (it != mt)           // need finite-length chunk
>>           fail();               //    of same type
>>
>> which I think also rejects tags inside indefinite strings. What am I
>> missing?
>>
>> Jeffrey
>>
>> On Thu, Dec 5, 2019 at 7:27 AM Faye Amacker <faye.github@gmail.com>
>> wrote:
>>
>>> While implementing support for tags, I ran into a scenario that might be
>>> errata or could use some clarification in 7049bis.
>>>
>>> Section 3.2.3 states:
>>>
>>> > Indefinite-length strings are represented by a byte containing the
>>> major type and additional information value of 31, followed by a series of
>>> zero or more byte or text strings (“chunks”) that have definite lengths,
>>> followed by the “break” stop code (Section 3.2.1). The data item
>>> represented by the indefinite-length string is the concatenation of the
>>> chunks (i.e., the empty byte or text string, respectively, if no chunk is
>>> present).
>>>
>>> And the pseudocode in Appendix C allows tags for chunks inside
>>> indefinite-length strings.
>>>
>>> Chunks are simply fragments to be concatenated, so tags applied to
>>> chunks doesn't seem intuitive.  Chunks are not intended for independent
>>> access like array elements.  Some tags (like #2 and #3) transform byte
>>> string into bignum which makes sense for arrays, not chunks.
>>>
>>> If tags must be applied to each chunk, there should be some text
>>> mentioning that because library authors might think it should be rejected
>>> or applied to the concatenated string rather than chunk.
>>>
>>> However, if the tag for a chunk applies to the entire concatenated
>>> string, then what happens when there are multiple chunks with different
>>> tags? Which tag wins?
>>>
>>> A simpler way forward is to treat tags on chunks as malformed.  If this
>>> is the way to go, then the pseudocode in Appendix C needs to be updated and
>>> an example could be added to Appendix G.
>>>
>>> GitHub issue for RFC 7049bis:
>>> https://github.com/cbor-wg/CBORbis/issues/148
>>> GitHub issue for my CBOR library:
>>> https://github.com/fxamacker/cbor/issues/44
>>> _______________________________________________
>>> CBOR mailing list
>>> CBOR@ietf.org
>>> https://www.ietf.org/mailman/listinfo/cbor
>>>
>>