Re: [COSE] tstr values for kty, alg, crv, etc.

Laurence Lundblade <lgl@island-resort.com> Wed, 28 July 2021 20:50 UTC

Return-Path: <lgl@island-resort.com>
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 5882E3A1F88 for <cose@ietfa.amsl.com>; Wed, 28 Jul 2021 13:50:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.894
X-Spam-Level:
X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 tUCwAgAywyFH for <cose@ietfa.amsl.com>; Wed, 28 Jul 2021 13:50:22 -0700 (PDT)
Received: from p3plsmtpa07-05.prod.phx3.secureserver.net (p3plsmtpa07-05.prod.phx3.secureserver.net [173.201.192.234]) (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 A7BE53A1F8B for <cose@ietf.org>; Wed, 28 Jul 2021 13:50:22 -0700 (PDT)
Received: from [192.168.0.100] ([71.92.144.145]) by :SMTPAUTH: with ESMTPSA id 8qVQm6Ich0LVM8qVQmw2yD; Wed, 28 Jul 2021 13:50:21 -0700
X-CMAE-Analysis: v=2.4 cv=JJ/+D+Gb c=1 sm=1 tr=0 ts=6101c30d a=E5cCtQzjhQJ5yJ7bKjC7Hg==:117 a=E5cCtQzjhQJ5yJ7bKjC7Hg==:17 a=gKmFwSsBAAAA:8 a=pGLkceISAAAA:8 a=I0CVDw5ZAAAA:8 a=48vgC7mUAAAA:8 a=c_kvtayOXd3qHdv-p4wA:9 a=QEXdDO2ut3YA:10 a=PtFgCIV0m5xhtFzs1iEA:9 a=2l8Rbuk2aaDfsJ_m:21 a=_W_S_7VecoQA:10 a=nnPW6aIcBuj1ljLj_o6Q:22 a=YdXdGVBxRxTCRzIkH2Jn:22 a=w1C3t2QeGrPiZgrLijVG:22
X-SECURESERVER-ACCT: lgl@island-resort.com
From: Laurence Lundblade <lgl@island-resort.com>
Message-Id: <41E79CBD-04D1-4C0F-BEE3-4F63780D514E@island-resort.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_1548EE5A-031D-48BC-B522-059D01216938"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\))
Date: Wed, 28 Jul 2021 13:50:20 -0700
In-Reply-To: <815DB7E9-555A-4A7D-B3DE-CC807DE3A222@tzi.org>
Cc: AJITOMI Daisuke <ajitomi@gmail.com>, cose@ietf.org
To: Carsten Bormann <cabo@tzi.org>
References: <CAFWvErVLfud5ffyzKdBJmzm7Wj+=osfZ0u7tKVpniicZDYqjxg@mail.gmail.com> <815DB7E9-555A-4A7D-B3DE-CC807DE3A222@tzi.org>
X-Mailer: Apple Mail (2.3608.120.23.2.1)
X-CMAE-Envelope: MS4xfAlR3C+Z87AQyjIOZCDnYZJejcHiqPZOnbSOfiIVd+jqutly6w1xfHRhhddXGkFyfTPEJcpfsUCgNHdsEuzzaDxSLuX0rFQYtkHoH/xSPsoFq2sFsfPP AM+CFezBPzm/oy7naW3rk98ORo/0FMDHRKFlx34QrhaI0ohpfuuI3/G+atYEDoqSnpX8cVPyQW7IFDh/Q27G1BwbdqVaZODNyJXSuhEV+D9bCZt7Xrksin8a
Archived-At: <https://mailarchive.ietf.org/arch/msg/cose/wxl-xDf2HMheZQZwCsNOTqdbbSA>
Subject: Re: [COSE] tstr values for kty, alg, crv, etc.
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: Wed, 28 Jul 2021 20:50:27 -0000

Yes, I much prefer int labels for a small C implementation. Adding support for tstr labels would noticeably increase code size. I hope no one registers a tstr label.  It seems unlikely because algorithms are relatively hard to invent and vet.

LL


> On Jul 28, 2021, at 5:47 AM, Carsten Bormann <cabo@tzi.org> wrote:
> 
> Hi Daisuke,
> 
>> On 2021-07-28, at 13:45, AJITOMI Daisuke <ajitomi@gmail.com <mailto:ajitomi@gmail.com>> wrote:
>> 
>> In my opinion, the tstr type for 'kty', 'alg', 'crv' or 'key_ops' is not necessary because I think the major advantage of COSE is its compactness,but I would like to know what you are assuming as the value of tstr.
> 
> The registrant gets the choice between a text string and an integer.
> 
> https://www.iana.org/assignments/cose/cose.xhtml <https://www.iana.org/assignments/cose/cose.xhtml> lists the registration procedures for certain ranges, e.g.:
> 
> https://www.iana.org/assignments/cose/cose.xhtml#algorithms <https://www.iana.org/assignments/cose/cose.xhtml#algorithms>
> 
> Range <sort_none.gif>	Registration Procedures <sort_up.gif>
> Strings of length 1	Standards Action With Expert Review
> Integer values between -256 and 255	Standards Action With Expert Review
> Strings of length 2	Specification Required
> Integer values from 256 to 65535	Specification Required
> Integer values from -65536 to -257	Specification Required
> Strings of length greater than 2	Expert Review
> Integer values greater than 65535	Expert Review
> 
> So labels the representations of which would be 1+0 and 1+1 bytes long require standards action, 1+2, specification required, and 1+>2, expert review.
> 
> It doesn’t look like anyone has felt a need to register a text string label for an algorithm ID yet; there are still quite a few 1+1 (and even a few 1+0!) values available for registration.
> 
> I would expect that, until we run out of codepoints, the registration of text labels will remain an occurrence for special circumstances (which means we might not be prepared for text labels when we finally actually need them).
> 
> Grüße, Carsten
> 
> _______________________________________________
> COSE mailing list
> COSE@ietf.org
> https://www.ietf.org/mailman/listinfo/cose