Re: [COSE] (still to be checked - your claimed one-line glitch in example added as courtesy) Re: (on ecdsa codepoints cose iana) Re: next steps for draft-ietf-lwig-curve-representations

Benjamin Kaduk <kaduk@mit.edu> Wed, 08 December 2021 23:09 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 B808B3A0809 for <cose@ietfa.amsl.com>; Wed, 8 Dec 2021 15:09:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.498
X-Spam-Level:
X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.399, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no 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 Aw2FMbVGU2Hu for <cose@ietfa.amsl.com>; Wed, 8 Dec 2021 15:09:47 -0800 (PST)
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 A98DE3A0805 for <cose@ietf.org>; Wed, 8 Dec 2021 15:09:46 -0800 (PST)
Received: from mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 1B8N9dST012868 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 8 Dec 2021 18:09:44 -0500
Date: Wed, 08 Dec 2021 15:09:39 -0800
From: Benjamin Kaduk <kaduk@mit.edu>
To: Rene Struik <rstruik.ext@gmail.com>
Cc: Ilari Liusvaara <ilariliusvaara@welho.com>, "cose@ietf.org" <cose@ietf.org>
Message-ID: <20211208230939.GF11486@mit.edu>
References: <6f0f99c0-6585-90cf-821a-8e61a395230f@gmail.com> <YaITRZ3O6XKSfXFm@LK-Perkele-VII2.locald> <72afe01c-98f5-46b4-35d0-21f7daab23ed@gmail.com> <3598d56f-a523-35dc-0db1-54400559ce94@gmail.com> <YafD+NO7mkXDvsor@LK-Perkele-VII2.locald> <23d5ec9a-0ace-04f2-1192-a1682eec90eb@gmail.com> <20211201192634.GT93060@mit.edu> <e02700ef-33a0-ea91-c32e-055f965cf6d0@gmail.com> <20211201202210.GU93060@mit.edu> <2390ed1e-0aa4-083c-099c-dbc996226408@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <2390ed1e-0aa4-083c-099c-dbc996226408@gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/cose/IXbNiMzF9JlKKZdWV6NpOWTdfIM>
Subject: Re: [COSE] (still to be checked - your claimed one-line glitch in example added as courtesy) Re: (on ecdsa codepoints cose iana) Re: next steps for draft-ietf-lwig-curve-representations
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, 08 Dec 2021 23:09:52 -0000

Hi Rene,

On Wed, Dec 01, 2021 at 05:16:33PM -0500, Rene Struik wrote:
> Hi Ben:
> 
> If one had wanted to be consistent in reasoning, one should also have 
> pulled draft-ietf-hash-algs out of the AUTH48 queue (since July 14, 2021 

It's not necessary to specifically pull the document out of the AUTH48
queue in order to place a hold on its publication while a (potential)
technical matter is resolved.  I noted this topic as a github issue on that
draft (https://github.com/cose-wg/X509/issues/42) and we will be making
sure that the github issue list is empty before approving publication of
that document.

> [1]) and should not have assigned a iana cose code point for shake128 
> (now, -18, see [2]). None of that happened either, despite these numbers 
> to be jealously treated as valuable assets.

Perhaps it should not have gotten a codepoint, but un-issuing a codepoint
is a very fraught operation.  Almost universally we add additional
references or notes rather than silently remove a registration.  For
example, the Russian GOST signature schemes should not have been assigned
values in the TLS SignatureAlgorithm registry
(https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-16),
as the values were previously in state "reserved" (not "unassigned"), but
since they had been assigned well before the error was discovered, it was
not reasonable to retroactively "un-assign" them and so we have left them
in place with a note about how they came to be (mis-)allocated.

In other words, I have to deal with the facts on the ground, not what I
would like them to be.

> Ref: [1] https://datatracker.ietf.org/doc/draft-ietf-cose-hash-algs/history/
> [2] https://www.iana.org/assignments/cose/cose.xhtml#algorithms
> 
> This being said, as already indicated I will do my own technical due 
> diligence (on the example E value computation), since do not base my own 
> findings on hearsay or unverified claims.

Thank you!

-Ben