Re: [Cbor] 🔔 WG adoption call on draft-bormann-cbor-tags-oid-07

Carsten Bormann <cabo@tzi.org> Thu, 16 July 2020 05:18 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 769B33A0E32 for <cbor@ietfa.amsl.com>; Wed, 15 Jul 2020 22:18:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.92
X-Spam-Level:
X-Spam-Status: No, score=-1.92 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] 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 TQ1qCkzoKSiL for <cbor@ietfa.amsl.com>; Wed, 15 Jul 2020 22:18:13 -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 E99693A0E31 for <cbor@ietf.org>; Wed, 15 Jul 2020 22:18:12 -0700 (PDT)
Received: from [192.168.217.116] (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 4B6jFY4sQHzyYt; Thu, 16 Jul 2020 07:18:09 +0200 (CEST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <4305.1594858862@localhost>
Date: Thu, 16 Jul 2020 07:18:09 +0200
Cc: "cbor@ietf.org" <cbor@ietf.org>
X-Mao-Original-Outgoing-Id: 616569488.963094-19693791e42f84220fdc30b22e922271
Content-Transfer-Encoding: quoted-printable
Message-Id: <342BB6D0-7D23-4925-9AE2-53AB48E37E97@tzi.org>
References: <C6F0CD6A-7AC7-4748-9352-B2B48AA36574@ericsson.com> <4305.1594858862@localhost>
To: Michael Richardson <mcr+ietf@sandelman.ca>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/d96hYOKLIo-A9f-H0Gsj5dgCUe0>
Subject: Re: [Cbor] 🔔 WG adoption call on draft-bormann-cbor-tags-oid-07
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, 16 Jul 2020 05:18:15 -0000

> Minor things I could see improving:
> 1) I think that the PCRE description in section 2.1 may be more heat than light.
>  For those who speak PCRE, it's great, and for those who don't, it just mystifies.
>  Those who speak PCRE probably already got the english text.

I generally benefit from having a concept explained in different ways.
This allows me to verify my nascent understanding.

(We need to make sure that it is clear that this is just explanation, an “example” in some way, and not the normative part — that is in RFC 6256.)

> 2) I have some concerns about the complexity of the Tag Factoring when it
>   comes to the nesting.

Indeed.  If we want to keep it, we need to find constraints on the interpretation that are manageable but maintain some usefulness.

>   Also, as I read it the first time, I thought it meant:
> 
>   <TBD111>"bstr for 1.3.6.1.2.1"[126,127,128,129]
> =>
>   [ <TBD111>"bstr for 1.3.6.1.2.1.126",
>     <TBD111>"bstr for 1.3.6.1.2.1.127",
>     <TBD111>"bstr for 1.3.6.1.2.1.128"
>     <TBD111>"bstr for 1.3.6.1.2.1.129"]
> 
>   but that's *NOT* the intention :-)

No.  Due to the way OIDs are used, that is also rarely what is needed.

> 3) It would probably be good to have a few use cases.
>   If there is an intention to be able to round trip signed certificates,
>   then this should be explicit.

You mean as in draft-mattsson-cose-cbor-cert-compress?
They get by without OIDs…

Grüße, Carsten