Re: [Cbor] draft-ietf-cbor-tags-oid-00.txt

Carsten Bormann <cabo@tzi.org> Sat, 01 August 2020 14:21 UTC

Return-Path: <cabo@tzi.org>
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 EA2693A0849 for <cbor@ietfa.amsl.com>; Sat, 1 Aug 2020 07:21:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.919
X-Spam-Level:
X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 OhKnZ8PWhMfM for <cbor@ietfa.amsl.com>; Sat, 1 Aug 2020 07:21:41 -0700 (PDT)
Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18F1D3A0A9B for <cbor@ietf.org>; Sat, 1 Aug 2020 07:21:40 -0700 (PDT)
Received: from [172.16.42.101] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4BJmYF1G43zydy; Sat, 1 Aug 2020 16:21:36 +0200 (CEST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <87h7tmxnxq.fsf@hobgoblin.ariadne.com>
Date: Sat, 01 Aug 2020 16:21:36 +0200
Cc: cbor@ietf.org
X-Mao-Original-Outgoing-Id: 617984495.851436-ae95b6f0403eaec1c7c17a485153744c
Content-Transfer-Encoding: quoted-printable
Message-Id: <18B0842C-B5B6-4F6D-B2F3-180A26B8F002@tzi.org>
References: <87h7tmxnxq.fsf@hobgoblin.ariadne.com>
To: "Dale R. Worley" <worley@ariadne.com>
X-Mailer: Apple Mail (2.3608.120.23.2.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/MJkZcHQY69fMfsSj4r7W9Vfpoqg>
Subject: Re: [Cbor] draft-ietf-cbor-tags-oid-00.txt
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: Sat, 01 Aug 2020 14:21:51 -0000

Hi Dale,


> On 2020-08-01, at 19:42, Dale R. Worley <worley@ariadne.com> wrote:
> 
> Reading this (and having read an earlier version), I really like the
> concept because I have a fondness for OIDs and think they should be used
> to name everything.

I hope not :-)

> But there is a welter of problems around being able to "factor" an OID
> tag out of an array or map.
> 
> Abstractly, if one can factor, one should be able to factor the tag out
> of any number of layers of structure.  The trouble with that is that it
> makes decoding difficult, as the decoder needs to keep the application
> of the tag in mind as it descends through structures.

Indeed.  I think we’ll have to restrict that to exactly one layer, i.e., an OID tag applied to an array or a map influences the elements/entries of that, nothing else.

(Note that this is also related to prefix compression, which is provided by packed cbor [draft-bormann-cbor-packed].)

> It would seem consistent that other tags might be defined with this
> behavior, in which case a decoder might need to keep several factored
> tags in mind as it is descending through structures.

I believe that is a complication worth arguing about.

> Comparing with other types, a homogeneous array of OIDs is very like a
> homogeneous array of integers, for which we already have a mechanism for
> one-dimensional arrays.  OID arrays could be handled similarly, although
> things are more complex because OIDs don't have a fixed-length encoding.

(Integers also don’t have a fixed length encoding when used in a tag 41 homogeneous array [RFC8746]; but there is no specific processing specified for these.)

> What isn't parallel with previous mechanisms is factoring from *maps*.
> And that's novel because the factored tag applies to the keys but not
> the values.  The reason for that is a bit arbitrary, and seems to be
> because that's convenient for encoding X.500 certificates.

Exactly.  Maps mapping OIDs to OIDs are not that useful, so applying the factoring to both rarely makes sense, AFAICS.  (Map) keys or values only makes more sense.  And I think keys wins,  because that is a likely case.

> Factoring seems to be hard to do; trying to make it semantically
> consistent and aligned with possible future tags with similar behavor
> seems to require complex behaviors in the decoder.  Though this proposal
> saves about 10% in X.500 distinguished name encoding.  Then again, are
> distinguished names ever used when they aren't paired with keys (which
> are much longer)?

(Crypto) keys don’t have to be much longer, see https://tools.ietf.org/html/draft-mattsson-cose-cbor-cert-compress-01#appendix-A for a worked example.

Grüße, Carsten