Re: [COSE] [Technical Errata Reported] RFC8152 (5669)

Benjamin Kaduk <kaduk@mit.edu> Sun, 24 March 2019 13:48 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: cose@ietfa.amsl.com
Delivered-To: cose@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 638A8127AC2 for <cose@ietfa.amsl.com>; Sun, 24 Mar 2019 06:48:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 hk_sshVlURiN for <cose@ietfa.amsl.com>; Sun, 24 Mar 2019 06:48:19 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 AA0AE12788C for <cose@ietf.org>; Sun, 24 Mar 2019 06:48:19 -0700 (PDT)
Received: from kduck.mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x2ODm8GQ013533 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 24 Mar 2019 09:48:10 -0400
Date: Sun, 24 Mar 2019 08:48:08 -0500
From: Benjamin Kaduk <kaduk@mit.edu>
To: Jim Schaad <ietf@augustcellars.com>
Cc: 'RFC Errata System' <rfc-editor@rfc-editor.org>, ekr@rtfm.com, ivaylo@ackl.io, linuxwolf+ietf@outer-planes.net, marco.tiloca@ri.se, cose@ietf.org
Message-ID: <20190324134808.GL77890@kduck.mit.edu>
References: <20190323172649.46604B81B5D@rfc-editor.org> <20190323221119.GJ88959@kduck.mit.edu> <02bc01d4e21b$7b5f6230$721e2690$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <02bc01d4e21b$7b5f6230$721e2690$@augustcellars.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/cose/6G60FwBkIs-PcSlRIh4brI0YNAU>
Subject: Re: [COSE] [Technical Errata Reported] RFC8152 (5669)
X-BeenThere: cose@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: CBOR Object Signing and Encryption <cose.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cose>, <mailto:cose-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cose/>
List-Post: <mailto:cose@ietf.org>
List-Help: <mailto:cose-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cose>, <mailto:cose-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 24 Mar 2019 13:48:21 -0000

On Sun, Mar 24, 2019 at 09:27:50AM +0100, Jim Schaad wrote:
> In the CBOR encoding it is pretty simple as non-negative integers and
> negative integers are encoded as separate types.

Right.  But if I look at, e.g.,

   COSE_Key = {
       1 => tstr / int,          ; kty
       ? 2 => bstr,              ; kid
       ? 3 => tstr / int,        ; alg
       ? 4 => [+ (tstr / int) ], ; key_ops
       ? 5 => bstr,              ; Base IV
       * label => values
   }

that has 'kty' as tstr / int, and 'int' is defined as either an unsigned
integer or a negative integer, so that doesn't really force it to be in the
unsigned space.

(I'm not terribly sure that that's the right CDDL in which values from the
registry go, though.)

-Ben