IETF Logo Mail Archive

Re: [Tls-reg-review] [IANA #1135278] Re: Request to register value in TLS bar registry (tls-parameters)

Benjamin Kaduk <kaduk@mit.edu> Fri, 06 August 2021 21:52 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: tls-reg-review@ietfa.amsl.com
Delivered-To: tls-reg-review@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 154B73A19B6 for <tls-reg-review@ietfa.amsl.com>; Fri, 6 Aug 2021 14:52:08 -0700 (PDT)
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 miJWKyEEQ977 for <tls-reg-review@ietfa.amsl.com>; Fri, 6 Aug 2021 14:52:04 -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 EFB1C3A19B5 for <tls-reg-review@ietf.org>; Fri, 6 Aug 2021 14:52:03 -0700 (PDT)
Received: from kduck.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 176LpMo0024894 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 6 Aug 2021 17:51:27 -0400
Date: Fri, 06 Aug 2021 14:51:22 -0700
From: Benjamin Kaduk <kaduk@mit.edu>
To: Yoav Nir <ynir.ietf@gmail.com>
Cc: iana-prot-param@iana.org, tls-reg-review@ietf.org, geni-cmc@mail.ru, kollegin@cryptopro.ru, alekseev@cryptopro.ru, svs@cryptopro.ru, ess@cryptopro.ru, beldmit@cryptocom.ru
Message-ID: <20210806215122.GN50759@kduck.mit.edu>
References: <RT-Ticket-1135278@icann.org> <1547039768.320095625@f553.i.mail.ru> <74E19738-0B8D-47EA-A684-A5A70E9BE487@gmail.com> <061D39FF-0538-498E-8485-33B92D6893AF@cryptopro.ru> <0408EA40-18F5-46A0-A5A8-BA667BFD4490@cryptopro.ru> <d665d166418d468c8c24bc45719d7e07@cryptopro.ru> <DA944331-8E53-445A-BB3B-58D1317519DB@gmail.com> <rt-4.4.3-8683-1549049524-638.1135278-37-0@icann.org> <5821D94F-9FFB-42B4-A057-6B61CE90E4A8@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <5821D94F-9FFB-42B4-A057-6B61CE90E4A8@gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls-reg-review/VFxQHEAit6Qg1fmnPwhRW2GUrKU>
Subject: Re: [Tls-reg-review] [IANA #1135278] Re: Request to register value in TLS bar registry (tls-parameters)
X-BeenThere: tls-reg-review@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TLS REVIEW <tls-reg-review.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls-reg-review>, <mailto:tls-reg-review-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls-reg-review/>
List-Post: <mailto:tls-reg-review@ietf.org>
List-Help: <mailto:tls-reg-review-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls-reg-review>, <mailto:tls-reg-review-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 06 Aug 2021 21:52:08 -0000

Sorry to dig up an old thread...

On Fri, Feb 01, 2019 at 09:50:41PM +0200, Yoav Nir wrote:
> Hi, Amanda.  Inline.
> 
> Authors: please check my answers, especially about the supported groups.
> 
> > On 1 Feb 2019, at 21:32, Amanda Baber via RT <iana-prot-param@iana.org> wrote:
> 
> > 3) For the TLS SignatureAlgorithm registrations, can you confirm that we should  start from value 64, the beginning of the Specification Required range? (Also because the values are marked "Reserved" rather than "Unassigned," is it possible to make registrations here without an approved document? Is "Reserved," which in RFC 8126 means "unavailable for assignment," meant to indicate availability here, as it sometimes did for older registries?)

No, "Reserved" does not indicate availability here.

The SignatureAlgorithm registry is nominally closed, having been superseded
by the SignatureScheme registry that effectively combines the
SignatureAlgorithm and HashAlgorithm registries and is conveyed in the same
protocol field.

https://datatracker.ietf.org/doc/html/rfc8447#section-15 is perhaps not as
clear about this as it could be, but the intent was to not make additional
allocations from this registry.

I think we need to convert these allocations into a handful of
corresponding entries in the SignatureScheme registry, to avoid burning a
sizeable chunk of the remaining SignatureScheme codepoint space.
Fortunately, they seem to only be paired with the 0x08 "intrinsic" hash
algorithm, which would help reduce the number of allocations needed in the
SignatureScheme registry.

-Ben

> Yes, starting at 64 is fine.
>

v2.23.0 | Report a Bug | By Email